From psadhukhan at openjdk.org  Wed Feb  1 03:27:52 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 1 Feb 2023 03:27:52 GMT
Subject: RFR: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url) [v4]
In-Reply-To: <YnXqa8KIQIlrArpqvqXpa1bmbHecnBqfTvE3JLFTDig=.e3a487b2-a2d1-4af9-971d-ce5fb530ebe7@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
 <YnXqa8KIQIlrArpqvqXpa1bmbHecnBqfTvE3JLFTDig=.e3a487b2-a2d1-4af9-971d-ce5fb530ebe7@github.com>
Message-ID: <YzgR2RtFbaZttKJHnrbf6XY3by4ZHsOaII8KEs3L72Q=.3194914d-32aa-43be-b06b-b58a2e00e059@github.com>

On Tue, 31 Jan 2023 18:36:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
>> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
>> So deprecating - for removal - and adding warnings now in the docs is appropriate.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300891

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12175


From tr at openjdk.org  Wed Feb  1 04:54:51 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 1 Feb 2023 04:54:51 GMT
Subject: RFR: 8300549: JFileChooser Approve button tooltip is null in Aqua
 L&F in CUSTOM_DIALOG mode [v2]
In-Reply-To: <RDnuNKckltw2aRuwLg94LV-sXNyPC3bG2JSrI81XKBM=.2c7a25e5-0729-46da-a2ec-8093dc32be60@github.com>
References: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
 <RDnuNKckltw2aRuwLg94LV-sXNyPC3bG2JSrI81XKBM=.2c7a25e5-0729-46da-a2ec-8093dc32be60@github.com>
Message-ID: <-ULEyxjmTpkz3U5HO_oQsXKv7j-wjypXpCbcUhHFaRE=.d5e354be-ef06-446b-8111-42c169643917@github.com>

On Wed, 25 Jan 2023 20:26:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Property added
>
> Changes requested by aivanov (Reviewer).

@aivanov-jdk CSR is required?

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

PR: https://git.openjdk.org/jdk/pull/12198


From psadhukhan at openjdk.org  Wed Feb  1 05:49:52 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 1 Feb 2023 05:49:52 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
Message-ID: <dLbse91LXDFXT0_2TlfVzlUtVLclI7Y70t98XrQth6w=.c71e26a1-f7b0-42a5-8b6c-fa08df18f5da@github.com>

On Tue, 31 Jan 2023 15:34:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

The scenario is covered by JCK test and present PR iteration does not show any issue

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

PR: https://git.openjdk.org/jdk/pull/11940


From avu at openjdk.org  Wed Feb  1 09:34:55 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 1 Feb 2023 09:34:55 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <vgh-OpjjgeBe1BlnHgC4YKTteMKDVhwxYk8QRQ4hxyI=.d5c58bd7-8935-427c-84bf-cd90dfe0e3a6@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
 <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>
 <vgh-OpjjgeBe1BlnHgC4YKTteMKDVhwxYk8QRQ4hxyI=.d5c58bd7-8935-427c-84bf-cd90dfe0e3a6@github.com>
Message-ID: <OeOTa_oK0pdfLzFdNXCrcsvW9emOtUqk7WhqFgzL6ps=.39cfc3f3-fa70-4fbb-976b-9ef268f0d087@github.com>

On Tue, 31 Jan 2023 16:20:38 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 92:
>> 
>>> 90: 
>>> 91:     private static int unicodeToUnits(int unicode, int dstOffset, char[] dst) {
>>> 92:         if (unicode >= 0x10000) {
>> 
>> Why can't you use public API that already does this ? [ ](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Character.html#toChars(int,char%5B%5D,int)) ?
>
> Which API exactly? I didn't know there is any, so I added this as a helper method.

I suppose it's https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Character.html#charCount(int)

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 10:37:55 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 10:37:55 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <OeOTa_oK0pdfLzFdNXCrcsvW9emOtUqk7WhqFgzL6ps=.39cfc3f3-fa70-4fbb-976b-9ef268f0d087@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
 <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>
 <vgh-OpjjgeBe1BlnHgC4YKTteMKDVhwxYk8QRQ4hxyI=.d5c58bd7-8935-427c-84bf-cd90dfe0e3a6@github.com>
 <OeOTa_oK0pdfLzFdNXCrcsvW9emOtUqk7WhqFgzL6ps=.39cfc3f3-fa70-4fbb-976b-9ef268f0d087@github.com>
Message-ID: <rbXCedjlweskgIXIzKUV_XdBEOq-cXxpobRqmz4rj5A=.b1c0fec2-f419-4c96-abea-92cd95058f24@github.com>

On Wed, 1 Feb 2023 09:31:35 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Which API exactly? I didn't know there is any, so I added this as a helper method.
>
> I suppose it's https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Character.html#charCount(int)

Oh thank you! There is `toChars` actually.

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

PR: https://git.openjdk.org/jdk/pull/4798


From pminborg at openjdk.org  Wed Feb  1 15:13:27 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 1 Feb 2023 15:13:27 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v2]
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <e0diTLO_z58sVZyjWMKvMWfcAPq5M_0dIQqru0--Pfc=.e8c039af-cdf7-4ce9-b59e-8e136cc05ddd@github.com>

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

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

  Add benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12204/files
  - new: https://git.openjdk.org/jdk/pull/12204/files/3fb71333..3b3873d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=00-01

  Stats: 95 lines in 1 file changed: 95 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12204.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12204/head:pull/12204

PR: https://git.openjdk.org/jdk/pull/12204


From duke at openjdk.org  Wed Feb  1 16:10:51 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 16:10:51 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>

> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
> It includes:
> - Bitmap glyph loading via Freetype
> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
> - Small fixes in related code like null-checks which could cause NPE & comment typos

Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Dynamic loading of ftcolor.h symbols on Linux.
 - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
 - Add braces to ifs.
 - Make tests headful.
 - Merge branch 'master' into JDK-8269806
 - Remove ftcolor.c
 - Skip tests if required font is absent
 - Fix pointer to jlong conversion on x86
 - Merge branch 'master' into JDK-8269806
 - Merge branch 'master' into JDK-8269806
 - ... and 16 more: https://git.openjdk.org/jdk/compare/60c535de...57c0b57d

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

Changes: https://git.openjdk.org/jdk/pull/4798/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=4798&range=17
  Stats: 2773 lines in 54 files changed: 2231 ins; 248 del; 294 mod
  Patch: https://git.openjdk.org/jdk/pull/4798.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/4798/head:pull/4798

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 16:10:53 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 16:10:53 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <rbXCedjlweskgIXIzKUV_XdBEOq-cXxpobRqmz4rj5A=.b1c0fec2-f419-4c96-abea-92cd95058f24@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
 <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>
 <vgh-OpjjgeBe1BlnHgC4YKTteMKDVhwxYk8QRQ4hxyI=.d5c58bd7-8935-427c-84bf-cd90dfe0e3a6@github.com>
 <OeOTa_oK0pdfLzFdNXCrcsvW9emOtUqk7WhqFgzL6ps=.39cfc3f3-fa70-4fbb-976b-9ef268f0d087@github.com>
 <rbXCedjlweskgIXIzKUV_XdBEOq-cXxpobRqmz4rj5A=.b1c0fec2-f419-4c96-abea-92cd95058f24@github.com>
Message-ID: <4BHI4rx_yhGQlYG5ePNN4ruT7hY4qjs-iqDp4JU5FKE=.20306c87-2f4e-4384-8e97-41f7ae7c3f7c@github.com>

On Wed, 1 Feb 2023 10:34:52 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> I suppose it's https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Character.html#charCount(int)
>
> Oh thank you! There is `toChars` actually.

Fixed

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 16:10:58 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 16:10:58 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v17]
In-Reply-To: <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <hF3_a7jZr5PrfWlGeu3r8585eaCKP1fLSNN0xhOGpzQ=.62524ef2-4726-4b87-bde8-3181bd8d70d3@github.com>
 <3JQGjb1CawgL8ov_zMsEB2Q6DcgQa2kchkjec85mAZM=.7d6eea32-0f50-43f7-88c3-b28572c47d6a@github.com>
Message-ID: <S7iDTvX4R34jgOkU9U949Bg2Ksi3O1XP9htUoN5w7KA=.2e25f47d-3b47-44d8-b964-ad7771a36684@github.com>

On Wed, 25 Jan 2023 18:42:24 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Skip tests if required font is absent
>
> src/java.desktop/macosx/classes/sun/font/CCharToGlyphMapper.java line 104:
> 
>> 102: 
>> 103:     public int charToVariationGlyph(int unicode, int variationSelector) {
>> 104:         if (variationSelector == 0) return charToGlyph(unicode);
> 
> We always use braces around the body, even for one line.

Fixed

> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 52:
> 
>> 50: // to build on older Linuxes, this is not a big problem,
>> 51: // as Linux uses bitmap emoji anyway.
>> 52: #if defined(_WIN32) || defined(__APPLE__)
> 
> Do we really have to disable coloured outlines because of what's available at build time ? Why can't we dynamically locate all the needed symbols at runtime ?

Fixed

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 16:25:42 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 16:25:42 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
Message-ID: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>

The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.

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

Commit messages:
 - 8301616: Drag & maximize to another monitor places window incorrectly (Windows)

Changes: https://git.openjdk.org/jdk/pull/12367/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301616
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12367.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12367/head:pull/12367

PR: https://git.openjdk.org/jdk/pull/12367


From aivanov at openjdk.org  Wed Feb  1 17:17:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 1 Feb 2023 17:17:52 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
 <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>
Message-ID: <TUJVNjtTk8wK4IxosL6vytgcGvK90auwNCQw_9otT1s=.25243377-6017-4c1a-b798-fac1dad5cf45@github.com>

On Tue, 31 Jan 2023 23:53:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> How the updated code is supposed to work if the worker will have some state updated by the "doInBackground" and used by the "done" method.

What do you mean?

~~Not much has changed to the way `done` is called.~~ Previously `doneEDT` was called from `FutureTask` implementation, its overridden `done` method. Now, `doneEDT` is called right from `doInBackground`.

Thus, if `cancel` was called on EDT, `doneEDT` and consequently `SwingWorker.done` were called on EDT (the latter was called synchronously). That is `doneEDT` was called on the thread which called `cancel`.

Now, `doneEDT` is always called on the background thread whether it's cancelled or not.

Yet no one should have depended on that because it was an implementation detail rather than a contract.

> I guess if the "doInBackground" will be canceled the "done" method may throw an exception?

Why is it? `done` cannot throw exceptions.

This entire scenario is where *`doInBackground` is cancelled* but `done` gets called before `doInBackground` exits.

Yet `get` method throws `CancellationException` if the work for `doInBackground` is cancelled. It's specified in the [`Future` interface](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/Future.html#get()).

> Do we have such usage in our codebase?

I found the [`CheckCancellationException.java`](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/SwingWorker/6608234/CheckCancellationException.java) test that you wrote. It verifies that calling `get` throws `CancellationException`.

`SwingWorker` is used in `JEditorPane` as well as in `jconsole` packages. Yet I didn't look into the details how it's used.

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

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Wed Feb  1 17:20:04 2023
From: duke at openjdk.org (duke)
Date: Wed, 1 Feb 2023 17:20:04 GMT
Subject: Withdrawn: 8298006: Build failure by maybe-uninitialized error on
 Linux s390x GCC8
In-Reply-To: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
References: <oTPDCZvNsMsmYwDy4x3m6MApqzv9TlBK9NMxa0E8mzQ=.5089f09f-3a11-426c-94e0-6b378365746f@github.com>
Message-ID: <psdZjSg1PWPEomEd50D1q1VWL5RvfvwVsO-0BfinV8c=.d8e0326b-de22-45c6-88ce-bbe7aec3bf20@github.com>

On Fri, 2 Dec 2022 08:41:18 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I changed GCC toolchain from GCC6 to GCC8 on SLES12SP5 Linux s390x.
> I could see following errors:
> 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c: In function 'allocateRasterArray':
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:2944:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> ?????????????????????????????(((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
> ?????????????????????????????????????????????????????????????????????~~~~^~~
> 
> 
> 
> src/java.desktop/share/native/libawt/awt/medialib/awt_ImagingLib.c:3129:73: error: 'roff[3]' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>                              (((*inP&rasterP->sppsm.maskArray[c]) >> roff[c])
>                                                                      ~~~~^~~
> 
> 
> According to error messages,
> roff and loff may not be initialized.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/11475


From prr at openjdk.org  Wed Feb  1 17:20:59 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 1 Feb 2023 17:20:59 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
Message-ID: <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>

On Wed, 1 Feb 2023 16:10:51 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Dynamic loading of ftcolor.h symbols on Linux.
>  - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
>  - Add braces to ifs.
>  - Make tests headful.
>  - Merge branch 'master' into JDK-8269806
>  - Remove ftcolor.c
>  - Skip tests if required font is absent
>  - Fix pointer to jlong conversion on x86
>  - Merge branch 'master' into JDK-8269806
>  - Merge branch 'master' into JDK-8269806
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/60c535de...57c0b57d

src/java.desktop/windows/data/fontconfig/fontconfig.properties line 249:

> 247: sequence.monospaced.x-windows-949=korean,alphabetic,dingbats,symbol
> 248: sequence.dialog.x-windows-949=alphabetic,korean,dingbats,symbol
> 249: sequence.dialoginput.x-windows-949=alphabetic,korean,dingbats,symbol

I'd like to understand the reasoning behind the changes I see in the windows fontconfig.properties

The effect of what I see is (if I have it right)
1) Make Segoe UI Symbol a "core" part of every font - with the consequence that you potentially change
the metrics of every logical font- something which is often a compatibility issue
2) You then go ahead and exclude virtually every code point in that font, which kind of
defeats the point of having it at all .. and is  I guess you want it to take precedence for
all those code points over the emoji font .. but not some others ??
It seems like additions in later versions of either font would mean there'd be updates
needed here.
And FWIW if the Emoji font isn't available they will now get missing glyphs

also you are making a policy decision here that apps which currently get ordinary
symbol chars will now get emojis for those codepoints, whether they want them or not.

I think need to look at what code points these fonts support ..  IMO the Emoji font
as a fall back should be for unicode specified Emoji code points which I expect
not to see in the normal symbol font ..

In other words, what I would *expect* is that you just added the emoji as another
fallback (somewhere after symbols) and changed NOTHING else in this file.

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 17:41:01 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 17:41:01 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
Message-ID: <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>

On Wed, 1 Feb 2023 17:18:27 GMT, Phil Race <prr at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
>> 
>>  - Dynamic loading of ftcolor.h symbols on Linux.
>>  - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
>>  - Add braces to ifs.
>>  - Make tests headful.
>>  - Merge branch 'master' into JDK-8269806
>>  - Remove ftcolor.c
>>  - Skip tests if required font is absent
>>  - Fix pointer to jlong conversion on x86
>>  - Merge branch 'master' into JDK-8269806
>>  - Merge branch 'master' into JDK-8269806
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/60c535de...57c0b57d
>
> src/java.desktop/windows/data/fontconfig/fontconfig.properties line 249:
> 
>> 247: sequence.monospaced.x-windows-949=korean,alphabetic,dingbats,symbol
>> 248: sequence.dialog.x-windows-949=alphabetic,korean,dingbats,symbol
>> 249: sequence.dialoginput.x-windows-949=alphabetic,korean,dingbats,symbol
> 
> I'd like to understand the reasoning behind the changes I see in the windows fontconfig.properties
> 
> The effect of what I see is (if I have it right)
> 1) Make Segoe UI Symbol a "core" part of every font - with the consequence that you potentially change
> the metrics of every logical font- something which is often a compatibility issue
> 2) You then go ahead and exclude virtually every code point in that font, which kind of
> defeats the point of having it at all .. and is  I guess you want it to take precedence for
> all those code points over the emoji font .. but not some others ??
> It seems like additions in later versions of either font would mean there'd be updates
> needed here.
> And FWIW if the Emoji font isn't available they will now get missing glyphs
> 
> also you are making a policy decision here that apps which currently get ordinary
> symbol chars will now get emojis for those codepoints, whether they want them or not.
> 
> I think need to look at what code points these fonts support ..  IMO the Emoji font
> as a fall back should be for unicode specified Emoji code points which I expect
> not to see in the normal symbol font ..
> 
> In other words, what I would *expect* is that you just added the emoji as another
> fallback (somewhere after symbols) and changed NOTHING else in this file.

Oh if only I remembered the details. Overall, such complex changes were made to support variation selectors. See: we have Segoe UI Emoji for colored emoji and Segoe UI Symbol for monochrome ones, each emoji by default must be rendered either colored or monochrome according to CLDR, so I add Segoe UI Symbol into fallback sequence, but exclude those ranges which shouldn't be rendered monochrome by default (that is, most of the characters). Then to make variation selector work, we ignore these exclusion ranges if monochrome selector is used or something like that. So this is some kind of hack to make variation selectors work without "branching" the fallback sequence and fit into existing architecture. I will look through the code to refresh the details and will let you know more.

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

PR: https://git.openjdk.org/jdk/pull/4798


From prr at openjdk.org  Wed Feb  1 17:50:59 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 1 Feb 2023 17:50:59 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
Message-ID: <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>

On Wed, 1 Feb 2023 17:37:47 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> src/java.desktop/windows/data/fontconfig/fontconfig.properties line 249:
>> 
>>> 247: sequence.monospaced.x-windows-949=korean,alphabetic,dingbats,symbol
>>> 248: sequence.dialog.x-windows-949=alphabetic,korean,dingbats,symbol
>>> 249: sequence.dialoginput.x-windows-949=alphabetic,korean,dingbats,symbol
>> 
>> I'd like to understand the reasoning behind the changes I see in the windows fontconfig.properties
>> 
>> The effect of what I see is (if I have it right)
>> 1) Make Segoe UI Symbol a "core" part of every font - with the consequence that you potentially change
>> the metrics of every logical font- something which is often a compatibility issue
>> 2) You then go ahead and exclude virtually every code point in that font, which kind of
>> defeats the point of having it at all .. and is  I guess you want it to take precedence for
>> all those code points over the emoji font .. but not some others ??
>> It seems like additions in later versions of either font would mean there'd be updates
>> needed here.
>> And FWIW if the Emoji font isn't available they will now get missing glyphs
>> 
>> also you are making a policy decision here that apps which currently get ordinary
>> symbol chars will now get emojis for those codepoints, whether they want them or not.
>> 
>> I think need to look at what code points these fonts support ..  IMO the Emoji font
>> as a fall back should be for unicode specified Emoji code points which I expect
>> not to see in the normal symbol font ..
>> 
>> In other words, what I would *expect* is that you just added the emoji as another
>> fallback (somewhere after symbols) and changed NOTHING else in this file.
>
> Oh if only I remembered the details. Overall, such complex changes were made to support variation selectors. See: we have Segoe UI Emoji for colored emoji and Segoe UI Symbol for monochrome ones, each emoji by default must be rendered either colored or monochrome according to CLDR, so I add Segoe UI Symbol into fallback sequence, but exclude those ranges which shouldn't be rendered monochrome by default (that is, most of the characters). Then to make variation selector work, we ignore these exclusion ranges if monochrome selector is used or something like that. So this is some kind of hack to make variation selectors work without "branching" the fallback sequence and fit into existing architecture. I will look through the code to refresh the details and will let you know more.

Please do provide details .. but I don't think we need to .. or should .. be making variation selectors work where the variations aren't supported by a single physical font.

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 18:06:02 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 18:06:02 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
Message-ID: <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>

On Wed, 1 Feb 2023 17:47:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> Oh if only I remembered the details. Overall, such complex changes were made to support variation selectors. See: we have Segoe UI Emoji for colored emoji and Segoe UI Symbol for monochrome ones, each emoji by default must be rendered either colored or monochrome according to CLDR, so I add Segoe UI Symbol into fallback sequence, but exclude those ranges which shouldn't be rendered monochrome by default (that is, most of the characters). Then to make variation selector work, we ignore these exclusion ranges if monochrome selector is used or something like that. So this is some kind of hack to make variation selectors work without "branching" the fallback sequence and fit into existing architecture. I will look through the code to refresh the details and will let you know more.
>
> Please do provide details .. but I don't think we need to .. or should .. be making variation selectors work where the variations aren't supported by a single physical font.

Why shouldn't we? That's how it works on Windows - monochrome emoji in Segoe UI Symbos and colored in Segoe UI Emoji, not very convenient, but I believe we have to deal with it. Native apps do support this and I guess OS font rendering has some emoji-specific branching to support this.

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

PR: https://git.openjdk.org/jdk/pull/4798


From prr at openjdk.org  Wed Feb  1 18:39:00 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 1 Feb 2023 18:39:00 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
 <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
Message-ID: <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>

On Wed, 1 Feb 2023 18:03:10 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> Please do provide details .. but I don't think we need to .. or should .. be making variation selectors work where the variations aren't supported by a single physical font.
>
> Why shouldn't we? That's how it works on Windows - monochrome emoji in Segoe UI Symbos and colored in Segoe UI Emoji, not very convenient, but I believe we have to deal with it. Native apps do support this and I guess OS font rendering has some emoji-specific branching to support this.

Are you sure ? I would expect that Segoe UI Emoji has a glyf table as well as a colr table.

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

PR: https://git.openjdk.org/jdk/pull/4798


From prr at openjdk.org  Wed Feb  1 19:04:03 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 1 Feb 2023 19:04:03 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
Message-ID: <O2tc9arUOsjikrBrcxUPDS-y2aprhZYUq_yD3_jenqM=.eea5b763-ac52-420e-ae75-8be8e62fb07f@github.com>

On Wed, 1 Feb 2023 16:10:51 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Dynamic loading of ftcolor.h symbols on Linux.
>  - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
>  - Add braces to ifs.
>  - Make tests headful.
>  - Merge branch 'master' into JDK-8269806
>  - Remove ftcolor.c
>  - Skip tests if required font is absent
>  - Fix pointer to jlong conversion on x86
>  - Merge branch 'master' into JDK-8269806
>  - Merge branch 'master' into JDK-8269806
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/60c535de...57c0b57d

> Make Segoe UI Symbol a "core" part of every font - with the consequence that you
> potentially change the metrics of every logical font- something which is often a compatibility issue

I want to make sure this part of the questions doesn't get lost - why did it move ?
The only reason I can think of is that you maybe found that exclusion ranges were not applied to fallbacks ?? That would be unfortunate since I don't think this should be moved.

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

PR: https://git.openjdk.org/jdk/pull/4798


From serb at openjdk.org  Wed Feb  1 19:45:17 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 1 Feb 2023 19:45:17 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <TUJVNjtTk8wK4IxosL6vytgcGvK90auwNCQw_9otT1s=.25243377-6017-4c1a-b798-fac1dad5cf45@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
 <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>
 <TUJVNjtTk8wK4IxosL6vytgcGvK90auwNCQw_9otT1s=.25243377-6017-4c1a-b798-fac1dad5cf45@github.com>
Message-ID: <f_rxRwVDCBbgBIV3MFirclUnTlz8ZEXacKsFeHKLEmA=.8160399a-31d8-45fb-bd29-2e85eb676110@github.com>

On Wed, 1 Feb 2023 17:15:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> SwingWorker is used in JEditorPane as well as in jconsole packages. Yet I didn't look into the details how it's used.

I think all of that usages by jconsole will start to throw the "CancellationException" in the "done" method since now we will start to call it. Not sure can it cause some issue or not.

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

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Wed Feb  1 21:16:25 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 21:16:25 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
 <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
 <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>
Message-ID: <gtF7oKLWghMLLzoiZIt-zi5iCc-SXZNyKZpBOl4oVBc=.30e3cbcd-9f64-4439-96ba-6adc30603985@github.com>

On Wed, 1 Feb 2023 18:36:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Why shouldn't we? That's how it works on Windows - monochrome emoji in Segoe UI Symbos and colored in Segoe UI Emoji, not very convenient, but I believe we have to deal with it. Native apps do support this and I guess OS font rendering has some emoji-specific branching to support this.
>
> Are you sure ? I would expect that Segoe UI Emoji has a glyf table as well as a colr table.

I thought so, but now you made me doubt. Anyway, I will read the code, recall this and will let you know what I find.

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 21:19:15 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 21:19:15 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
Message-ID: <-sz6uyIlCW7b9DxhbiI3p5l0olHftCp1jbVOP_M6usI=.ba08490d-9a77-43a4-8279-ad81a87da690@github.com>

On Wed, 1 Feb 2023 16:10:51 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> It was implemented in JetBrains Runtime a year ago and was ported & refactored for this PR
>> It includes:
>> - Bitmap glyph loading via Freetype
>> - Manual scaling & transformation of bitmap glyphs with nearest-neighbor or bilinear-mipmap style algorithms depending on the text antialiasing hint
>> - Storing BGRA glyphs in glyph cache & rendering them as plain images, as currently used XRender text drawing functions doesn't support colored glyphs
>> - Small fixes in related code like null-checks which could cause NPE & comment typos
>
> Nikita Gubarkov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:
> 
>  - Dynamic loading of ftcolor.h symbols on Linux.
>  - Replace unicodeToUnits with Character.toChars in CCharToGlyphMapper
>  - Add braces to ifs.
>  - Make tests headful.
>  - Merge branch 'master' into JDK-8269806
>  - Remove ftcolor.c
>  - Skip tests if required font is absent
>  - Fix pointer to jlong conversion on x86
>  - Merge branch 'master' into JDK-8269806
>  - Merge branch 'master' into JDK-8269806
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/60c535de...57c0b57d

Yes, the reason for moving it was that exclusion ranges don't work with fallbacks ?

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb  1 22:42:33 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 22:42:33 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <gtF7oKLWghMLLzoiZIt-zi5iCc-SXZNyKZpBOl4oVBc=.30e3cbcd-9f64-4439-96ba-6adc30603985@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
 <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
 <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>
 <gtF7oKLWghMLLzoiZIt-zi5iCc-SXZNyKZpBOl4oVBc=.30e3cbcd-9f64-4439-96ba-6adc30603985@github.com>
Message-ID: <4xoGJjdHdkrDjsc77ahROvDdvdXzKd3vlasVT0zH6VU=.b5fa7af5-75b6-40e2-b4e0-b2619c1e3bba@github.com>

On Wed, 1 Feb 2023 21:13:55 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> Are you sure ? I would expect that Segoe UI Emoji has a glyf table as well as a colr table.
>
> I thought so, but now you made me doubt. Anyway, I will read the code, recall this and will let you know what I find.

Well, what I did find so far:
* Segoe UI Emoji does have `FE0F` UVS (colored selector), but no `FE0E` (monochrome).
* Segoe UI Symbol doesn't have any UVS.

So fonts alone will not guide us to a correct glyph.
However, we can ignore COLR table and render base glyphs from Segoe UI Emoji to achieve monochrome effect, so we actually can have both mono/color inside Segoe UI Emoji alone (but we would still have to determine whether to use mono or color ourselves).
But these base glyphs are not the same as in Segoe UI Symbol and I can clearly see that every Windows app which respect variation selectors, renders monochrome ones using Segoe UI Symbol, not base glyphs from Segoe UI Emoji.

I will try to investigate this further, but so far it looks to me like to support variation selectors the way native apps do, we need to use some kind of hardcoded tables, like those exclusion ranges, because:
1. We don't know whether character must be draw mono/colored by default, fonts doesn't tell us, only CLDR does.
2. Even if we somehow know the default variant, looking for `FE0F` selector will lead us to to Segoe UI Emoji, but `FE0E` - nowhere.

Ideas?

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

PR: https://git.openjdk.org/jdk/pull/4798


From aivanov at openjdk.org  Wed Feb  1 22:43:23 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 1 Feb 2023 22:43:23 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <f_rxRwVDCBbgBIV3MFirclUnTlz8ZEXacKsFeHKLEmA=.8160399a-31d8-45fb-bd29-2e85eb676110@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
 <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>
 <TUJVNjtTk8wK4IxosL6vytgcGvK90auwNCQw_9otT1s=.25243377-6017-4c1a-b798-fac1dad5cf45@github.com>
 <f_rxRwVDCBbgBIV3MFirclUnTlz8ZEXacKsFeHKLEmA=.8160399a-31d8-45fb-bd29-2e85eb676110@github.com>
Message-ID: <Bz8iLwtz63cRgitbhRlph6Nq9ioLasVfn2FZmSsXZPY=.43ed9884-5d0a-47c6-a1a2-da254bc4e51a@github.com>

On Wed, 1 Feb 2023 19:42:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > SwingWorker is used in JEditorPane as well as in jconsole packages. Yet I didn't look into the details how it's used.
> 
> I think all of that usages by jconsole will start to throw the "CancellationException" in the "done" method since now we will start to call it. Not sure can it cause some issue or not.

Why do you think so?

The `done` method hasn't thrown `CancellationException`, and it will not. If it had thrown the exception, Prasanta's test would've caught it.

Additionally, the `done` method *must* be called. It was called before, it is called now.

I cannot understand your concern.

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

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Wed Feb  1 23:09:33 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 23:09:33 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <4xoGJjdHdkrDjsc77ahROvDdvdXzKd3vlasVT0zH6VU=.b5fa7af5-75b6-40e2-b4e0-b2619c1e3bba@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
 <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
 <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>
 <gtF7oKLWghMLLzoiZIt-zi5iCc-SXZNyKZpBOl4oVBc=.30e3cbcd-9f64-4439-96ba-6adc30603985@github.com>
 <4xoGJjdHdkrDjsc77ahROvDdvdXzKd3vlasVT0zH6VU=.b5fa7af5-75b6-40e2-b4e0-b2619c1e3bba@github.com>
Message-ID: <OJ1NfIgF0JdTDMd4cLyLyY5Cg4a0W0b2AQqIB5Fg-7c=.e4bfcb3d-b277-456e-81bd-2513817d321f@github.com>

On Wed, 1 Feb 2023 22:39:48 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> I thought so, but now you made me doubt. Anyway, I will read the code, recall this and will let you know what I find.
>
> Well, what I did find so far:
> * Segoe UI Emoji does have `FE0F` UVS (colored selector), but no `FE0E` (monochrome).
> * Segoe UI Symbol doesn't have any UVS.
> 
> So fonts alone will not guide us to a correct glyph.
> However, we can ignore COLR table and render base glyphs from Segoe UI Emoji to achieve monochrome effect, so we actually can have both mono/color inside Segoe UI Emoji alone (but we would still have to determine whether to use mono or color ourselves).
> But these base glyphs are not the same as in Segoe UI Symbol and I can clearly see that every Windows app which respect variation selectors, renders monochrome ones using Segoe UI Symbol, not base glyphs from Segoe UI Emoji.
> 
> I will try to investigate this further, but so far it looks to me like to support variation selectors the way native apps do, we need to use some kind of hardcoded tables, like those exclusion ranges, because:
> 1. We don't know whether character must be draw mono/colored by default, fonts doesn't tell us, only CLDR does.
> 2. Even if we somehow know the default variant, looking for `FE0F` selector will lead us to to Segoe UI Emoji, but `FE0E` - nowhere.
> 
> Ideas?

So I restored the original idea.
1. Place Symbol into main font sequences to preceed the Emoji and be able to have exclusion ranges
2. Exclude everything that should be colored by default
3. One more hack in composite mapper - ignore exclude ranges when variation selector is specified

Results:
* No selector, default mono: will be handled by Symbol
* No selector, default color: skip Symbol because excluded, handle by Emoji
* FE0F (color): skip Symbol because it doesn't define mapping for this selector, handle by Emoji
* FE0E (mono): skip Symbol & Emoji & remaining fonts because they don't define this selector. No glyph found, so try again without selector, but ignoring exclusion ranges - handle by Symbol

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

PR: https://git.openjdk.org/jdk/pull/4798


From dnguyen at openjdk.org  Wed Feb  1 23:26:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 1 Feb 2023 23:26:23 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v4]
In-Reply-To: <faAg_l3mXZDdEBAJHX4vR966zDgWXgEaTZsISNZtUeY=.f2f11807-9105-47b5-bc93-9f82f24e974e@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <faAg_l3mXZDdEBAJHX4vR966zDgWXgEaTZsISNZtUeY=.f2f11807-9105-47b5-bc93-9f82f24e974e@github.com>
Message-ID: <So1sQBy1ufhszMW8Kn-uIPikvpP55Ew1BWApyrt_3NI=.37c8dd7c-7e44-41a9-96be-323cb563222f@github.com>

On Mon, 30 Jan 2023 23:19:35 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete
>
> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
>  - added debug statements
>  - re-test
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
>  - added robot wait to prevent mouse position from being calculated before robot finishes mouseMove

test/jdk/java/awt/Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java line 97:

> 95: //            if (!Util.testBoundsColor(bounds, color, 5, 1000, robot)) {
> 96: //                throw new RuntimeException(getErrorText("Robot.getPixelColor", i));
> 97: //            }

Why was this commented out? And if it's commented out, isn't it better to just be removed? It still seems to pass with it included. 

I tested with the newest changes. It passes on my local machine running macOS Monterey 12.3.1 using dual monitors. The test does create a yellow frame on both monitors and the color check passes in the test. I ran the test 5 times locally without any failures.

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

PR: https://git.openjdk.org/jdk/pull/10363


From duke at openjdk.org  Wed Feb  1 23:43:32 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 1 Feb 2023 23:43:32 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <OJ1NfIgF0JdTDMd4cLyLyY5Cg4a0W0b2AQqIB5Fg-7c=.e4bfcb3d-b277-456e-81bd-2513817d321f@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
 <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
 <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>
 <gtF7oKLWghMLLzoiZIt-zi5iCc-SXZNyKZpBOl4oVBc=.30e3cbcd-9f64-4439-96ba-6adc30603985@github.com>
 <4xoGJjdHdkrDjsc77ahROvDdvdXzKd3vlasVT0zH6VU=.b5fa7af5-75b6-40e2-b4e0-b2619c1e3bba@github.com>
 <OJ1NfIgF0JdTDMd4cLyLyY5Cg4a0W0b2AQqIB5Fg-7c=.e4bfcb3d-b277-456e-81bd-2513817d321f@github.com>
Message-ID: <fzTNuZov9bq2-3W1yuLVOz8Q6LkOwCOF8JC2RaVxJv4=.2c652631-54fe-4b89-a65e-408b4afe5c67@github.com>

On Wed, 1 Feb 2023 23:06:50 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> Well, what I did find so far:
>> * Segoe UI Emoji does have `FE0F` UVS (colored selector), but no `FE0E` (monochrome).
>> * Segoe UI Symbol doesn't have any UVS.
>> 
>> So fonts alone will not guide us to a correct glyph.
>> However, we can ignore COLR table and render base glyphs from Segoe UI Emoji to achieve monochrome effect, so we actually can have both mono/color inside Segoe UI Emoji alone (but we would still have to determine whether to use mono or color ourselves).
>> But these base glyphs are not the same as in Segoe UI Symbol and I can clearly see that every Windows app which respect variation selectors, renders monochrome ones using Segoe UI Symbol, not base glyphs from Segoe UI Emoji.
>> 
>> I will try to investigate this further, but so far it looks to me like to support variation selectors the way native apps do, we need to use some kind of hardcoded tables, like those exclusion ranges, because:
>> 1. We don't know whether character must be draw mono/colored by default, fonts doesn't tell us, only CLDR does.
>> 2. Even if we somehow know the default variant, looking for `FE0F` selector will lead us to to Segoe UI Emoji, but `FE0E` - nowhere.
>> 
>> Ideas?
>
> So I restored the original idea.
> 1. Place Symbol into main font sequences to preceed the Emoji and be able to have exclusion ranges
> 2. Exclude everything that should be colored by default
> 3. One more hack in composite mapper - ignore exclude ranges when variation selector is specified
> 
> Results:
> * No selector, default mono: will be handled by Symbol
> * No selector, default color: skip Symbol because excluded, handle by Emoji
> * FE0F (color): skip Symbol because it doesn't define mapping for this selector, handle by Emoji
> * FE0E (mono): skip Symbol & Emoji & remaining fonts because they don't define this selector. No glyph found, so try again without selector, but ignoring exclusion ranges - handle by Symbol

The best idea that came to my mind so far is to insert proxy "emoji" mapper into fallback sequence, which will handle default variations and stuff and then forward calls to real mono/color mapper. And this logic can also be reused in other OSes. What do you think?

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

PR: https://git.openjdk.org/jdk/pull/4798


From psadhukhan at openjdk.org  Thu Feb  2 04:19:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 2 Feb 2023 04:19:24 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
Message-ID: <53rJeFxp6wmEPfYETzPKWrG6aiEu3xt_LZlaOm3q4KI=.d9f6f949-22e0-4e21-94e8-bcec39a70c75@github.com>

On Tue, 31 Jan 2023 15:34:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Implementation of `done` method is not changed to cause/invoke `CancellationException `.
 As per [JDK-6608234](https://bugs.openjdk.org/browse/JDK-6608234) "CancellationException" will be called for `get` method if `cancel `is invoked, which is still valid/working and as mentioned, we have not seen any exception either in jtreg or in jck with updated fix.

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Thu Feb  2 06:12:05 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 06:12:05 GMT
Subject: RFR: 8301567: The
 test/jdk/java/awt/AppContext/ApplicationThreadsStop/java.policy is unused
Message-ID: <86QBcu6i526TV5xFNw3VO51kwBQAWHSAB637SIT2kxI=.3b3861d3-093f-45bc-aee8-edaa38208359@github.com>

The test ApplicationThreadsStop.java was removed by the [JDK-8289616](https://bugs.openjdk.org/browse/JDK-8289616) but the related java.policy was not deleted.

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

Commit messages:
 - 8301567: The test/jdk/java/awt/AppContext/ApplicationThreadsStop/java.policy

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

PR: https://git.openjdk.org/jdk/pull/12356


From jwaters at openjdk.org  Thu Feb  2 06:19:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 06:19:03 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows for
 libawt and libsaproc
Message-ID: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>

Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

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

Commit messages:
 - Resolve reordering issues in libawt and libsaproc

Changes: https://git.openjdk.org/jdk/pull/12382/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12382&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301659
  Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12382.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12382/head:pull/12382

PR: https://git.openjdk.org/jdk/pull/12382


From dholmes at openjdk.org  Thu Feb  2 06:47:23 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Feb 2023 06:47:23 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <GscycQ56rVy-uNOMZeuGwcY79cdbgV0fn3ewsCZB49w=.ffeecf81-87c1-4481-b980-f78e4f364614@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

Bundling unrelated changes like this together is rarely a good idea, but these changes seem trivial enough. I thought the compiler already checked fields where initialized in declaration order, but I guess not with Visual Studio.

Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12382


From psadhukhan at openjdk.org  Thu Feb  2 10:46:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 2 Feb 2023 10:46:15 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers
Message-ID: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>

In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.

Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.

No regression test is added as it can be verified by SwingSet2 Tabledemo..

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

Commit messages:
 - JDK-7154070: in SwingSet2, switching between LaFs it's easy to lose JTable dividers

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

PR: https://git.openjdk.org/jdk/pull/12385


From psadhukhan at openjdk.org  Thu Feb  2 11:00:44 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 2 Feb 2023 11:00:44 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v2]
In-Reply-To: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
Message-ID: <XHc8ZI5d_GeJCyshR2a3Jnrc8MzEH0F9_47ob_jkhYc=.0b8dead3-05e0-4be0-90ec-8f919a3529ef@github.com>

> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
> 
> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
> 
> No regression test is added as it can be verified by SwingSet2 Tabledemo..

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

  Use separate showHorizLines, showVerticalLines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12385/files
  - new: https://git.openjdk.org/jdk/pull/12385/files/8d625dc8..10fedd4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=00-01

  Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12385.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12385/head:pull/12385

PR: https://git.openjdk.org/jdk/pull/12385


From aivanov at openjdk.org  Thu Feb  2 11:52:32 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 11:52:32 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
Message-ID: <9HE4W7h3ekbNhG9w7H0TXaAljMGrM8IagKBSJswMV6M=.d342dd39-e986-4d97-b4d7-e593bc722076@github.com>

On Tue, 31 Jan 2023 15:34:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 36:

> 34: public class TestDoneBeforeDoInBackground {
> 35: 
> 36:     static boolean doInBackground = false;

Suggestion:

    private static boolean doInBackground = false;

Let's make it private too.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 38:

> 36:     static boolean doInBackground = false;
> 37:     private static final int WAIT_TIME = 200;
> 38:     private static final long CLEANUP_TIME = 3000;

Suggestion:

    private static final long CLEANUP_TIME = 1000;

1 second is enough for automatic test.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 89:

> 87:             throw new RuntimeException("done didn't complete in time");
> 88:         }
> 89:         System.out.println("doInBackground " + doInBackground);

Suggestion:

        System.out.println("doInBackground = " + doInBackground);

Maybe add getState() too?

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

PR: https://git.openjdk.org/jdk/pull/11940


From kevinw at openjdk.org  Thu Feb  2 12:15:21 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 2 Feb 2023 12:15:21 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

(In the description you mean it is required for JDK-8288293.)
Could we say in the bug exactly when this is an issue (maybe it's a certain compiler?), and include a copy of the error or warning that is seen?  That would help somebody find this change if they hit the issue, and clarify if it's a build failure or something else.
The changes look ok to me.

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

PR: https://git.openjdk.org/jdk/pull/12382


From psadhukhan at openjdk.org  Thu Feb  2 13:06:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 2 Feb 2023 13:06:15 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v9]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <S2imGP-XJPEIBsklCMSeSh72VdCBKN3x3RAlWoTCF1M=.af694050-8648-4e92-a178-36854d058695@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/f3b59bd2..09d43ae7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=07-08

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Thu Feb  2 13:14:07 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 2 Feb 2023 13:14:07 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/09d43ae7..76b02ea3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  2 13:14:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 13:14:09 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
Message-ID: <HC2VsbaoNV22bEi17DLzeFWdEKtT22gyi93K2dXkSBA=.78361cee-df71-4d0a-8f8c-c6647935ec46@github.com>

On Thu, 2 Feb 2023 13:10:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  2 14:09:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 14:09:36 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <Sa1gLIhTRLVWgm6lakg3UvYAg8PX-CTEKW6jzqN9GQg=.06fde780-2127-47cd-8d4b-d1926e9b059c@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8301659](https://bugs.openjdk.org/browse/JDK-8301659)

Looks good to me.

David's comment sheds some light on why it's needed. I will appreciate if you add more details though.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12382


From aivanov at openjdk.org  Thu Feb  2 14:09:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 14:09:38 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
 <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
Message-ID: <XrwA3Xmm0rplAkGF8OIl0DDaHkPf86Su7ZgbdmeUgrQ=.53f3f983-668a-4bee-9004-fb2abb9a6471@github.com>

On Thu, 2 Feb 2023 12:12:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Could we say in the bug exactly when this is an issue (maybe it's a certain compiler?), and include a copy of the error or warning that is seen?

Yes, I agree. The change is simple enough yet there are no details why it's needed.

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

PR: https://git.openjdk.org/jdk/pull/12382


From pminborg at openjdk.org  Thu Feb  2 15:04:57 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:04:57 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v3]
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <j_I89bmSRiKzBcN0t4m-FxKFABD5pisKPrkVeORuAIM=.3587f329-a2ca-4779-8a6f-e17f3cacebc9@github.com>

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

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

  Fix problem in benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12204/files
  - new: https://git.openjdk.org/jdk/pull/12204/files/3b3873d5..68d72946

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=01-02

  Stats: 12 lines in 1 file changed: 0 ins; 8 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12204.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12204/head:pull/12204

PR: https://git.openjdk.org/jdk/pull/12204


From pminborg at openjdk.org  Thu Feb  2 15:05:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 15:05:00 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v2]
In-Reply-To: <e0diTLO_z58sVZyjWMKvMWfcAPq5M_0dIQqru0--Pfc=.e8c039af-cdf7-4ce9-b59e-8e136cc05ddd@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
 <e0diTLO_z58sVZyjWMKvMWfcAPq5M_0dIQqru0--Pfc=.e8c039af-cdf7-4ce9-b59e-8e136cc05ddd@github.com>
Message-ID: <t9pMCgx7-yAlMygcXq7EvzpTS8nXG3d9riiDMYFDaW0=.61e42f00-ac4e-41b4-9d5d-7b937b9ac8eb@github.com>

On Wed, 1 Feb 2023 15:13:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>> 
>> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add benchmark

Here are some benchmarks:


Baseline (JDK21, master (called Java 20 below))
Benchmark                       Mode  Cnt  Score   Error  Units
ImageInputStreamBench.readInt   avgt   15  1.289 ? 0.029  ns/op
ImageInputStreamBench.readLong  avgt   15  1.308 ? 0.017  ns/op

Patch (called Java 21 below)
Benchmark                       Mode  Cnt  Score   Error  Units
ImageInputStreamBench.readInt   avgt   15  0.946 ? 0.046  ns/op
ImageInputStreamBench.readLong  avgt   15  0.954 ? 0.010  ns/op



![image](https://user-images.githubusercontent.com/7457876/216359253-a2594137-0c7f-4fac-a673-177576fc43ed.png)

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

PR: https://git.openjdk.org/jdk/pull/12204


From jwaters at openjdk.org  Thu Feb  2 15:17:29 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 15:17:29 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
 <AzWzL8X2e1ARIp9ViZQwHImDyROCQfbPh99l8Gi4otU=.0263bbd4-bca4-4df2-acf2-f36def422430@github.com>
Message-ID: <lB3Mi8iJyWhrXB7XDBfE281RkA59eqJsnysMp617rn8=.0365956e-a05a-45a3-9d84-d8a19d305d53@github.com>

On Thu, 2 Feb 2023 12:12:37 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> (In the description you mean it is required for JDK-8288293.)

Ah, yes that was what I meant, sorry for the oversight

kevin and aivanov: When compiling for Windows with gcc instead of Visual C++, gcc will raise the following warnings
`m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
`bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc

(Note that the Windows JDK itself cannot yet be compiled with gcc, these errors were found on a local experimental branch)

Both will also get promoted to errors and cause build failures in debug or adhoc builds. All can be easily suppressed by disabling the reorder warning, but there isn't much of a reason to do so when you could easily fix the initializer list directly

Thanks for the heads up, will add more details to the main PR comment and the linked entry in JBS first

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

PR: https://git.openjdk.org/jdk/pull/12382


From jwaters at openjdk.org  Thu Feb  2 15:22:47 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 15:22:47 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <8D8bf0czao126AMkWYxQVSA-mDR-DmOcGQuwY3sWCO0=.b89461d3-31e0-4bbc-a854-35eb732238f6@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
> 
> gcc will fail to compile a Windows JDK with the following errors, which causes a build failure eventually:
> `GDIHashtable.cpp: m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
> `sawindbg.cpp: bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc
> 
> Reordering these initializer lists to appear in the order of their declarations will resolve the build failure

Thanks David and aivanov for the reviews

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

PR: https://git.openjdk.org/jdk/pull/12382


From jwaters at openjdk.org  Thu Feb  2 15:25:41 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Feb 2023 15:25:41 GMT
Subject: Integrated: 8301659: Resolve initialization reordering issues on
 Windows for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <xklgJrsjRNAroKzwiPD-4gXAm0b2Rlr_rwlEgqDer3c=.deccbf60-dd1e-43cc-9374-eada1919f4e9@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
> 
> gcc will fail to compile a Windows JDK with the following errors, which causes a build failure eventually:
> `GDIHashtable.cpp: m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
> `sawindbg.cpp: bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc
> 
> Reordering these initializer lists to appear in the order of their declarations will resolve the build failure

This pull request has now been integrated.

Changeset: 725d57b2
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/725d57b2e2b78c1536d8a4adae67b27a2c8aee21
Stats:     5 lines in 2 files changed: 2 ins; 1 del; 2 mod

8301659: Resolve initialization reordering issues on Windows for libawt and libsaproc

Reviewed-by: dholmes, aivanov

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

PR: https://git.openjdk.org/jdk/pull/12382


From kevinw at openjdk.org  Thu Feb  2 16:20:01 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 2 Feb 2023 16:20:01 GMT
Subject: RFR: 8301659: Resolve initialization reordering issues on Windows
 for libawt and libsaproc
In-Reply-To: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
References: <MIdZrLSkxIN8XF3QtAZD5VfbmcZcyjs7T27nTsbKDAg=.fa2ac899-c8d3-415d-beab-d8216358b487@github.com>
Message-ID: <MHx-lBRP_VZQVnin8JvUWPlQbLJQ7Vd9dfOMYtJ2m6E=.133dbb92-3381-4395-8480-39f76cda4372@github.com>

On Thu, 2 Feb 2023 06:12:20 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Small, trivial change to resolve initialization order reordering in constructors, required for [JDK-8288293](https://bugs.openjdk.org/browse/JDK-8288293)
> 
> gcc will fail to compile a Windows JDK with the following errors, which causes a build failure eventually:
> `GDIHashtable.cpp: m_nCounter is initialized before m_nDestroyPeriod [-Werror=reorder]` for libawt
> `sawindbg.cpp: bytePtr is initialized before releaseMode [-Werror=reorder]` for libsaproc
> 
> Reordering these initializer lists to appear in the order of their declarations will resolve the build failure

Thanks for filling in the details 8-)

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

PR: https://git.openjdk.org/jdk/pull/12382


From dnguyen at openjdk.org  Thu Feb  2 16:41:25 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 2 Feb 2023 16:41:25 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has bad
 font color
Message-ID: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>

Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).

SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.

An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.

After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

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

Commit messages:
 - Add listener & conditional for setEnabled in DLCR. Create test for JComboBox

Changes: https://git.openjdk.org/jdk/pull/12390/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7093691
  Stats: 190 lines in 3 files changed: 183 ins; 6 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12390.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12390/head:pull/12390

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Thu Feb  2 16:41:25 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 2 Feb 2023 16:41:25 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color
In-Reply-To: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
Message-ID: <o02VpvmB6muijK_rmBH461v121XSN281q3NEnerFCpM=.098d3fbd-dca6-4af3-9468-b13346a666c8@github.com>

On Thu, 2 Feb 2023 16:33:06 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

Here are screenshots of the bug and the UI elements after the fix is applied.

Disabled JComboBox with DLCR before fix:
<img width="644" alt="Screen Shot 2023-02-01 at 3 52 46 PM" src="https://user-images.githubusercontent.com/96267980/216385047-a9bde4f9-c33d-430b-b68f-f4a9df8bf8a9.png">

After fix:
<img width="643" alt="Screen Shot 2023-02-01 at 3 46 19 PM" src="https://user-images.githubusercontent.com/96267980/216384982-1407f271-d28d-423f-843b-5e1c59ba984c.png">

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

PR: https://git.openjdk.org/jdk/pull/12390


From psadhukhan at openjdk.org  Thu Feb  2 17:31:03 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 2 Feb 2023 17:31:03 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v3]
In-Reply-To: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
Message-ID: <9C6ux9NaUB4i-TihEpD6Zv4LzfqDJBvfoEfKvOIxLqo=.e385cd9a-55c2-47c7-8754-3676a42ac4dc@github.com>

> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
> 
> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
> 
> No regression test is added as it can be verified by SwingSet2 Tabledemo..

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

  Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12385/files
  - new: https://git.openjdk.org/jdk/pull/12385/files/10fedd4f..7f099481

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=01-02

  Stats: 89 lines in 1 file changed: 89 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12385.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12385/head:pull/12385

PR: https://git.openjdk.org/jdk/pull/12385


From psadhukhan at openjdk.org  Thu Feb  2 17:39:53 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 2 Feb 2023 17:39:53 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
Message-ID: <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>

> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
> 
> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
> 
> No regression test is added as it can be verified by SwingSet2 Tabledemo..

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

  test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12385/files
  - new: https://git.openjdk.org/jdk/pull/12385/files/7f099481..c1d64881

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=02-03

  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/12385.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12385/head:pull/12385

PR: https://git.openjdk.org/jdk/pull/12385


From aivanov at openjdk.org  Thu Feb  2 17:58:25 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 17:58:25 GMT
Subject: RFR: 8300549: JFileChooser Approve button tooltip is null in Aqua
 L&F in CUSTOM_DIALOG mode [v2]
In-Reply-To: <RDnuNKckltw2aRuwLg94LV-sXNyPC3bG2JSrI81XKBM=.2c7a25e5-0729-46da-a2ec-8093dc32be60@github.com>
References: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
 <RDnuNKckltw2aRuwLg94LV-sXNyPC3bG2JSrI81XKBM=.2c7a25e5-0729-46da-a2ec-8093dc32be60@github.com>
Message-ID: <lcTc-qSyTg4Fr_rHI3bUjYsRw01GPAy6HoGTTp0VSa4=.57861175-caf4-428f-8eaa-84c5c1fdd3e3@github.com>

On Wed, 25 Jan 2023 20:26:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Property added
>
> Changes requested by aivanov (Reviewer).

> @aivanov-jdk CSR is required?

I don't think it's required. It isn't specified anywhere, Aqua L&F isn't public API.

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

PR: https://git.openjdk.org/jdk/pull/12198


From rriggs at openjdk.org  Thu Feb  2 19:18:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 2 Feb 2023 19:18:26 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v3]
In-Reply-To: <j_I89bmSRiKzBcN0t4m-FxKFABD5pisKPrkVeORuAIM=.3587f329-a2ca-4779-8a6f-e17f3cacebc9@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
 <j_I89bmSRiKzBcN0t4m-FxKFABD5pisKPrkVeORuAIM=.3587f329-a2ca-4779-8a6f-e17f3cacebc9@github.com>
Message-ID: <doj0tfo-LObflO9ZKWAQ5J7Mm3btecZTVbkUtwpK0Vg=.e13304b2-f3c0-4f89-96be-740604de8efd@github.com>

On Thu, 2 Feb 2023 15:04:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>> 
>> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix problem in benchmark

Looks good. 
Thanks for the JMH benchmarks.

src/java.base/share/classes/jdk/internal/util/ByteArrayLittleEndian.java line 420:

> 418:     }
> 419: 
> 420:     private static VarHandle create(Class<?> viewArrayClass) {

Renaming the method to `createLittleEndian` would make the static assignments at the top unambiguous.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12204


From pminborg at openjdk.org  Thu Feb  2 19:29:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 2 Feb 2023 19:29:05 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v4]
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <ViV_w-br_doi4-b5zLEUNoco0hH-5OOIDGMZVCHIRsU=.149b260e-a50c-4c22-8782-ddb1c29ec1bd@github.com>

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

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

  Rename to createLittleEndian

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12204/files
  - new: https://git.openjdk.org/jdk/pull/12204/files/68d72946..d58e22fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12204&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12204


From honkar at openjdk.org  Thu Feb  2 20:19:18 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 2 Feb 2023 20:19:18 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have border
 rendering issues when scaled
Message-ID: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>

FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 

All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.

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

Commit messages:
 - added updateColor(), isActive() to MetalBorder
 - test summary changes
 - deleted InternalFrameBorderTest
 - moved corner var to AbstractMetalBorder
 - sealed abstract class, record changes
 - initial commit, consolidated test case

Changes: https://git.openjdk.org/jdk/pull/12391/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294484
  Stats: 786 lines in 3 files changed: 389 ins; 327 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/12391.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12391/head:pull/12391

PR: https://git.openjdk.org/jdk/pull/12391


From honkar at openjdk.org  Thu Feb  2 20:34:20 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 2 Feb 2023 20:34:20 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v2]
In-Reply-To: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
Message-ID: <KGPdmam3RDd8f9RL7V1gKXzxxDxGrd_mxsvtfaUoIBg=.6c3b6d87-2dea-410b-9991-2879058ba4fe@github.com>

> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
> 
> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.

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

  removed unused import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12391/files
  - new: https://git.openjdk.org/jdk/pull/12391/files/9e32240f..a0e8b29e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12391


From avu at openjdk.org  Thu Feb  2 20:34:30 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 2 Feb 2023 20:34:30 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
In-Reply-To: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
Message-ID: <79vTmtVRLhmgiKw2RMUcOQW2NwihzZWKhLhKZCyjnYk=.c2ccbcae-704b-4f2b-8551-a0b8cf44f2fb@github.com>

On Wed, 1 Feb 2023 16:17:02 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.

Marked as reviewed by avu (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12367


From serb at openjdk.org  Thu Feb  2 20:39:29 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 20:39:29 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
In-Reply-To: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
Message-ID: <WoRGGIbLP6ZeiD3nBLm_Wr64IsVYGi_aHM7GfEDjmRI=.388a4404-1d1d-4614-aa57-29bd6416891e@github.com>

On Wed, 1 Feb 2023 16:17:02 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2190:

> 2188:         Devices::InstanceAccess devices;
> 2189:         AwtWin32GraphicsDevice *device = devices->GetDevice(m_screenNum);
> 2190:         if (device && !::IsZoomed(GetHWnd())) {

How does the maximization+drag work in WIndows11 if the maximized bounds are set(so the window will not fill the whole screen)? It will reset the zoom state during the drag, it will maximize the window on the new screen, or it will rescale the window on the new screen?

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

PR: https://git.openjdk.org/jdk/pull/12367


From serb at openjdk.org  Thu Feb  2 20:43:26 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 20:43:26 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v2]
In-Reply-To: <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>
Message-ID: <3U2Z--A3Y8Dn-tFKZu_SpkWPVrQtwsWKHuDxs5Qc4FE=.631a319c-ea66-4017-af5f-36f5ee2afb02@github.com>

On Fri, 27 Jan 2023 04:25:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Iterate all installed L&F

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 58:

> 56:             SwingUtilities.updateComponentTreeUI(fc);
> 57:             System.out.println("Nimbus font " + fc.getFont());
> 58:             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));

This will test the uninstallDefaults for the Nimbus only. I think you need to iterate all L&F twice and for the different ones check that the font will be changed(if L&Fs use different fonts).

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

PR: https://git.openjdk.org/jdk/pull/12180


From serb at openjdk.org  Thu Feb  2 20:44:31 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 20:44:31 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image [v2]
In-Reply-To: <UuDy9HQjg4biGyePMid3CcKI7Gy6wcFJ2maahGycatQ=.441da7b3-38a1-44ab-8617-f6ca00aebe25@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <UuDy9HQjg4biGyePMid3CcKI7Gy6wcFJ2maahGycatQ=.441da7b3-38a1-44ab-8617-f6ca00aebe25@github.com>
Message-ID: <XHOrciS3wTQwbCaXBw6oHkLg39CuzkCXFl46ZQW2Gv4=.1f935b44-5eef-45b4-ac52-4674e38b3a56@github.com>

On Thu, 26 Jan 2023 09:28:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300929: Avoid unnecessary array fill after creation in java.awt.image
>   
>   add clarifying comment for the 'bandOffsets'

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12147


From serb at openjdk.org  Thu Feb  2 20:48:27 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 20:48:27 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <Bz8iLwtz63cRgitbhRlph6Nq9ioLasVfn2FZmSsXZPY=.43ed9884-5d0a-47c6-a1a2-da254bc4e51a@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
 <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>
 <TUJVNjtTk8wK4IxosL6vytgcGvK90auwNCQw_9otT1s=.25243377-6017-4c1a-b798-fac1dad5cf45@github.com>
 <f_rxRwVDCBbgBIV3MFirclUnTlz8ZEXacKsFeHKLEmA=.8160399a-31d8-45fb-bd29-2e85eb676110@github.com>
 <Bz8iLwtz63cRgitbhRlph6Nq9ioLasVfn2FZmSsXZPY=.43ed9884-5d0a-47c6-a1a2-da254bc4e51a@github.com>
Message-ID: <9a1Xx24wnPzW71tdL3XSkj9JxTdhOLQzC9Apxr3ssXc=.be39d0f4-3b46-46a3-9dea-42fd7f5f1094@github.com>

On Wed, 1 Feb 2023 22:40:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Why do you think so?
> 
> The `done` method hasn't thrown `CancellationException`, and it will not. If it had thrown the exception, Prasanta's test would've caught it.

But the `done` methods which call "get" will start to throw that exception, right? Implementation of "done" method in the jconsole actually calls "get". Is that pattern could be common?

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Thu Feb  2 21:01:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 21:01:30 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
Message-ID: <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>

On Thu, 2 Feb 2023 13:14:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 309:

> 307:                             setState(StateValue.DONE);
> 308:                             doneEDT();
> 309:                         }

Probably been discussed already, but this will not follow this part of spec:

 * Before the {@code doInBackground} method is invoked on a <i>worker</i> thread,
 * {@code SwingWorker} notifies any {@code PropertyChangeListeners} about the
 * {@code state} property change to {@code StateValue.STARTED}.  After the
 * {@code doInBackground} method is finished the {@code done} method is
 * executed.  Then {@code SwingWorker} notifies any {@code PropertyChangeListeners}
 * about the {@code state} property change to {@code StateValue.DONE}.

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Thu Feb  2 21:09:26 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 21:09:26 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <9a1Xx24wnPzW71tdL3XSkj9JxTdhOLQzC9Apxr3ssXc=.be39d0f4-3b46-46a3-9dea-42fd7f5f1094@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
 <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>
 <TUJVNjtTk8wK4IxosL6vytgcGvK90auwNCQw_9otT1s=.25243377-6017-4c1a-b798-fac1dad5cf45@github.com>
 <f_rxRwVDCBbgBIV3MFirclUnTlz8ZEXacKsFeHKLEmA=.8160399a-31d8-45fb-bd29-2e85eb676110@github.com>
 <Bz8iLwtz63cRgitbhRlph6Nq9ioLasVfn2FZmSsXZPY=.43ed9884-5d0a-47c6-a1a2-da254bc4e51a@github.com>
 <9a1Xx24wnPzW71tdL3XSkj9JxTdhOLQzC9Apxr3ssXc=.be39d0f4-3b46-46a3-9dea-42fd7f5f1094@github.com>
Message-ID: <-212upGQDPr6x4TIFfveUGYGYW8SET3R-QlW9M2SfEY=.65bf6da6-b169-45f3-a13b-d755e93e2216@github.com>

On Thu, 2 Feb 2023 20:45:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Why do you think so?
> > The `done` method hasn't thrown `CancellationException`, and it will not. If it had thrown the exception, Prasanta's test would've caught it.
> 
> But the `done` methods which call "get" will start to throw that exception, right? Implementation of "done" method in the jconsole actually calls "get". Is that pattern could be common?

I see your point now, yes that should not be a problem.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  2 21:09:27 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 21:09:27 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v8]
In-Reply-To: <-212upGQDPr6x4TIFfveUGYGYW8SET3R-QlW9M2SfEY=.65bf6da6-b169-45f3-a13b-d755e93e2216@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <L4aiGpssMPzU3v5ngSkcPTh6sRQtrOk4CMbrDv7I2d4=.093bd80a-c140-439c-93a4-4aad0245cac4@github.com>
 <2iqTlhXat4p5UQFfk340a4WvY36dOlon_LGhMFX_4Ls=.598001c6-43c3-492c-9b78-974afc3d43a8@github.com>
 <TUJVNjtTk8wK4IxosL6vytgcGvK90auwNCQw_9otT1s=.25243377-6017-4c1a-b798-fac1dad5cf45@github.com>
 <f_rxRwVDCBbgBIV3MFirclUnTlz8ZEXacKsFeHKLEmA=.8160399a-31d8-45fb-bd29-2e85eb676110@github.com>
 <Bz8iLwtz63cRgitbhRlph6Nq9ioLasVfn2FZmSsXZPY=.43ed9884-5d0a-47c6-a1a2-da254bc4e51a@github.com>
 <9a1Xx24wnPzW71tdL3XSkj9JxTdhOLQzC9Apxr3ssXc=.be39d0f4-3b46-46a3-9dea-42fd7f5f1094@github.com>
 <-212upGQDPr6x4TIFfveUGYGYW8SET3R-QlW9M2SfEY=.65bf6da6-b169-45f3-a13b-d755e93e2216@github.com>
Message-ID: <MDyyY52C6LY2O1Zd6BmCVXKYqAg-GynqJDgu_I63g0U=.4b670ccc-72fc-4d3a-8c29-81179ae7b8e5@github.com>

On Thu, 2 Feb 2023 21:04:20 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Why do you think so?
> > The `done` method hasn't thrown `CancellationException`, and it will not. If it had thrown the exception, Prasanta's test would've caught it.
> 
> But the `done` methods which call "get" will start to throw that exception, right? Implementation of "done" method in the jconsole actually calls "get". Is that pattern could be common?

`done` which calls `get` **will *continue*** to see this exception: nothing has changed. As soon as `cancel` is called, `get` throws `CancellationException` (unless `doInBackground` completed by that time). The old code threw the exception just like the new one does.

You can take Prasanta's test and add a call to `get` into `done` ? it throws `CancellationException` if run with jdk19 or 21 without the fix. It still throws `CancellationException` with the fix. (I've just done it to confirm my own sanity. You can do it too.)

Nothing has changed in this regard.

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

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Thu Feb  2 21:17:30 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 2 Feb 2023 21:17:30 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
In-Reply-To: <WoRGGIbLP6ZeiD3nBLm_Wr64IsVYGi_aHM7GfEDjmRI=.388a4404-1d1d-4614-aa57-29bd6416891e@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
 <WoRGGIbLP6ZeiD3nBLm_Wr64IsVYGi_aHM7GfEDjmRI=.388a4404-1d1d-4614-aa57-29bd6416891e@github.com>
Message-ID: <Rwig96Joy3bNbOD1c3Pyg2PPnyMPXk40EvDRHHbIgr0=.1de94c5b-2fd7-4251-a040-3a53370adb17@github.com>

On Thu, 2 Feb 2023 20:36:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 2190:
> 
>> 2188:         Devices::InstanceAccess devices;
>> 2189:         AwtWin32GraphicsDevice *device = devices->GetDevice(m_screenNum);
>> 2190:         if (device && !::IsZoomed(GetHWnd())) {
> 
> How does the maximization+drag work in WIndows11 if the maximized bounds are set(so the window will not fill the whole screen)? It will reset the zoom state during the drag, it will maximize the window on the new screen, or it will rescale the window on the new screen?

Maximized bounds are treated as absolute virtual screen coordinates, when maximized, window will be reshaped to that specific bounds no matter what monitor it is currently on. That is, when dragging to fullscreen from monitor 1 to 2 while maximized bound are in 1st monitor, it will just jump back and maximize there.
Also when maximized bounds are set, window looks awful on Win11 with caption looking wider than client area, but that's another topic.
So I found that my fix breaks maximized bounds logic - window jumps somewhere outside the monitor.
I guess we can apply this `AwtWindow::CheckWindowDPIChange()` jump for maximized windows, but only for those components which are overriden by maximized bounds (not `Integer.MAX_VALUE`).

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

PR: https://git.openjdk.org/jdk/pull/12367


From aivanov at openjdk.org  Thu Feb  2 21:20:31 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 21:20:31 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
Message-ID: <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>

On Thu, 2 Feb 2023 20:58:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 309:
> 
>> 307:                             setState(StateValue.DONE);
>> 308:                             doneEDT();
>> 309:                         }
> 
> Probably been discussed already, but this will not follow this part of spec:
> 
>  * Before the {@code doInBackground} method is invoked on a <i>worker</i> thread,
>  * {@code SwingWorker} notifies any {@code PropertyChangeListeners} about the
>  * {@code state} property change to {@code StateValue.STARTED}.  After the
>  * {@code doInBackground} method is finished the {@code done} method is
>  * executed.  Then {@code SwingWorker} notifies any {@code PropertyChangeListeners}
>  * about the {@code state} property change to {@code StateValue.DONE}.

Valid concern.

I mentioned it before [here](https://github.com/openjdk/jdk/pull/11940#issuecomment-1407690445), yet I forgot about this later on.

Changing the order of the calls should be enough.

I guess we should verify this condition in the test, what do you think?

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  2 21:20:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 21:20:35 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
Message-ID: <ftQniVmbYb6IjCgUmsS4LhSV8Kfgc0KzdTwaucmbZjE=.007ca84d-2717-458e-b7cd-dadf6b675921@github.com>

On Thu, 2 Feb 2023 13:14:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 43:

> 41:     public static void main(String[] args) throws InterruptedException {
> 42:         SwingWorker<String, String> worker =
> 43:             new SwingWorker<String, String>() {

Suggestion:

        SwingWorker<String, String> worker = new SwingWorker<>() {

Just noticed, it can be simplified.

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Thu Feb  2 21:20:33 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 21:20:33 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
Message-ID: <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>

On Thu, 2 Feb 2023 21:13:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 309:
>> 
>>> 307:                             setState(StateValue.DONE);
>>> 308:                             doneEDT();
>>> 309:                         }
>> 
>> Probably been discussed already, but this will not follow this part of spec:
>> 
>>  * Before the {@code doInBackground} method is invoked on a <i>worker</i> thread,
>>  * {@code SwingWorker} notifies any {@code PropertyChangeListeners} about the
>>  * {@code state} property change to {@code StateValue.STARTED}.  After the
>>  * {@code doInBackground} method is finished the {@code done} method is
>>  * executed.  Then {@code SwingWorker} notifies any {@code PropertyChangeListeners}
>>  * about the {@code state} property change to {@code StateValue.DONE}.
>
> Valid concern.
> 
> I mentioned it before [here](https://github.com/openjdk/jdk/pull/11940#issuecomment-1407690445), yet I forgot about this later on.
> 
> Changing the order of the calls should be enough.
> 
> I guess we should verify this condition in the test, what do you think?

But it did not work as expected before the fix as well since the "notification and done" work in parallel anyway.

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Thu Feb  2 21:31:28 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 2 Feb 2023 21:31:28 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
Message-ID: <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>

On Thu, 2 Feb 2023 21:17:23 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Valid concern.
>> 
>> I mentioned it before [here](https://github.com/openjdk/jdk/pull/11940#issuecomment-1407690445), yet I forgot about this later on.
>> 
>> Changing the order of the calls should be enough.
>> 
>> I guess we should verify this condition in the test, what do you think?
>
> But it did not work as expected before the fix as well since the "notification and done" work in parallel anyway.

It could be tested by flushing and blocking the EDT in the listener. That will allow us to check the order of events posted from the listener and from the "doneEDT".

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  2 21:31:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 21:31:29 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
Message-ID: <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>

On Thu, 2 Feb 2023 21:28:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> But it did not work as expected before the fix as well since the "notification and done" work in parallel anyway.
>
> It could be tested by flushing and blocking the EDT in the listener. That will allow us to check the order of events posted from the listener and from the "doneEDT".

I haven't verified it, but I think it worked as it's stated: `done` is called first, then listeners are notified. According to the order of calls

https://github.com/openjdk/jdk/blob/b00b70c2400d28070d26630614a010bc52237827/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L310-L313

`SwingWorker.done` gets invoked first followed by `setState` which, in its turn, notifies the listeners.

At this time, as you pointed out, the order is reversed:

https://github.com/openjdk/jdk/blob/76b02ea3a8add954705d6df7f91f5896d141b02d/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L307-L308

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  2 21:38:30 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 21:38:30 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
Message-ID: <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>

On Thu, 2 Feb 2023 21:28:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It could be tested by flushing and blocking the EDT in the listener. That will allow us to check the order of events posted from the listener and from the "doneEDT".
>
> I haven't verified it, but I think it worked as it's stated: `done` is called first, then listeners are notified. According to the order of calls
> 
> https://github.com/openjdk/jdk/blob/b00b70c2400d28070d26630614a010bc52237827/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L310-L313
> 
> `SwingWorker.done` gets invoked first followed by `setState` which, in its turn, notifies the listeners.
> 
> At this time, as you pointed out, the order is reversed:
> 
> https://github.com/openjdk/jdk/blob/76b02ea3a8add954705d6df7f91f5896d141b02d/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L307-L308

> It could be tested by flushing and blocking the EDT in the listener. That will allow us to check the order of events posted from the listener and from the "doneEDT".

Is flushing required?

Two `AtomicBoolean`s should do the job. EDT can't process two events simultaneously, one follows the other. So, `done` is expected to be called while both are `false`, and it sets its own flag to `true`; the listener should be called second, so its flag is `false` and `done`'s flag is `true`.

I'll leave it to Pransanta to figure out the details.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  2 23:13:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 23:13:53 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
In-Reply-To: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
Message-ID: <Hv8InrRTDvbI9dzFAgKUc-ZPUbu4-CxO9R7qvS0yxvU=.b8893379-3992-43a0-bc40-6498fdc29057@github.com>

On Wed, 1 Feb 2023 16:17:02 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

> The `AwtWindow::CheckWindowDPIChange()` hack was introduced for popup windows and breaks maximization logic, so reshape window only if it's not maximized.

I tested it and it looks good.

In my case the title bar and client area were always aligned, yet the window was maximized incorrectly.

I ran the client tests, all's green.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12367


From aivanov at openjdk.org  Thu Feb  2 23:24:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Feb 2023 23:24:04 GMT
Subject: RFR: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image [v2]
In-Reply-To: <UuDy9HQjg4biGyePMid3CcKI7Gy6wcFJ2maahGycatQ=.441da7b3-38a1-44ab-8617-f6ca00aebe25@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
 <UuDy9HQjg4biGyePMid3CcKI7Gy6wcFJ2maahGycatQ=.441da7b3-38a1-44ab-8617-f6ca00aebe25@github.com>
Message-ID: <iudHEe6NDPyjmfFFAkcfGt2zvR6fS9Xzd8x0DFF3uhM=.ea6a6ed7-8616-4b56-89ec-80052f043524@github.com>

On Thu, 26 Jan 2023 09:28:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300929: Avoid unnecessary array fill after creation in java.awt.image
>   
>   add clarifying comment for the 'bandOffsets'

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12147


From psadhukhan at openjdk.org  Fri Feb  3 04:29:55 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 04:29:55 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v2]
In-Reply-To: <3U2Z--A3Y8Dn-tFKZu_SpkWPVrQtwsWKHuDxs5Qc4FE=.631a319c-ea66-4017-af5f-36f5ee2afb02@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>
 <3U2Z--A3Y8Dn-tFKZu_SpkWPVrQtwsWKHuDxs5Qc4FE=.631a319c-ea66-4017-af5f-36f5ee2afb02@github.com>
Message-ID: <vVc3a2bDk1asUSE-EJePj1D0jgJKCONgUAgsPo5-CHs=.384bb789-a8bc-42e6-9164-d7032beeb05a@github.com>

On Thu, 2 Feb 2023 20:40:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Iterate all installed L&F
>
> test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 58:
> 
>> 56:             SwingUtilities.updateComponentTreeUI(fc);
>> 57:             System.out.println("Nimbus font " + fc.getFont());
>> 58:             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));
> 
> This will test the uninstallDefaults for the Nimbus only. I think you need to iterate all L&F twice and for the different ones check that the font will be changed(if L&Fs use different fonts).

It tests for Nimbus as the fix is for that only. 
It tests transition from Metal/Motif/Windows/WIndowsClassis->Nimbus->Metal/Motif/Windows/WindowsClassis for windows platform, say.
We can enhance the test to test other L&F uninstallDefaults as part of test enhancement exercise in a separate JBS, which I dont think is needed for this nimbus JBS fix. 
I hope it should not be a problem and should not be a blocker for this fix approval..

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

PR: https://git.openjdk.org/jdk/pull/12180


From serb at openjdk.org  Fri Feb  3 05:20:50 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 3 Feb 2023 05:20:50 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v2]
In-Reply-To: <KGPdmam3RDd8f9RL7V1gKXzxxDxGrd_mxsvtfaUoIBg=.6c3b6d87-2dea-410b-9991-2879058ba4fe@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
 <KGPdmam3RDd8f9RL7V1gKXzxxDxGrd_mxsvtfaUoIBg=.6c3b6d87-2dea-410b-9991-2879058ba4fe@github.com>
Message-ID: <dzET0s1JMWEu-TTFNzK3Jlt2ZRNawoJgRHqlaCDbmnI=.3b4dbda7-c340-4edb-b6dd-3d7a7bba3275@github.com>

On Thu, 2 Feb 2023 20:34:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
>> 
>> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed unused import

test/jdk/javax/swing/plaf/metal/MetalBorders/ScaledMetalBorderTest.java line 2:

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

the comma after the second year should be added.

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

PR: https://git.openjdk.org/jdk/pull/12391


From serb at openjdk.org  Fri Feb  3 06:12:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 3 Feb 2023 06:12:52 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
In-Reply-To: <Rwig96Joy3bNbOD1c3Pyg2PPnyMPXk40EvDRHHbIgr0=.1de94c5b-2fd7-4251-a040-3a53370adb17@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
 <WoRGGIbLP6ZeiD3nBLm_Wr64IsVYGi_aHM7GfEDjmRI=.388a4404-1d1d-4614-aa57-29bd6416891e@github.com>
 <Rwig96Joy3bNbOD1c3Pyg2PPnyMPXk40EvDRHHbIgr0=.1de94c5b-2fd7-4251-a040-3a53370adb17@github.com>
Message-ID: <gzTV82RQHAdCp0YK2W282OVr-Uu2nvf8k7vjnU1VIvU=.ac954f42-5378-450e-88a7-03b820579673@github.com>

On Thu, 2 Feb 2023 21:15:05 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

> I guess we can apply this AwtWindow::CheckWindowDPIChange() jump for maximized windows, but only for those components which are overriden by maximized bounds (not Integer.MAX_VALUE).

Do you mean apply "CheckWindowDPIChange" to all windows, except maximized in full screen(Integer.MAX_VALUE)? It sounds good, I guess it is not possible to do that in Windows 10. So that change should not break something.

I wonder what is the order of events the Windows send to the application, at what moment do we get the maximization/zoom property - after the drag to the second screen or before?

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

PR: https://git.openjdk.org/jdk/pull/12367


From aturbanov at openjdk.org  Fri Feb  3 06:55:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 3 Feb 2023 06:55:05 GMT
Subject: Integrated: 8300929: Avoid unnecessary array fill after creation in
 java.awt.image
In-Reply-To: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
References: <o4FML4K8bsOOVDp0xo00gHPgOeTYa8u-5El70bRg8Fw=.9e856563-769a-4ce6-83f8-10118faf0308@github.com>
Message-ID: <wx03SaxbS1krf6Xj-A5JYnTx32PhKQpuf_312k4E4tU=.b7acecc4-d973-462f-a4fd-15bf4ac51b9e@github.com>

On Mon, 23 Jan 2023 17:20:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

This pull request has now been integrated.

Changeset: 406021ad
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/406021ad585eec1ec007535ed6b08c2ebffec2ee
Stats:     39 lines in 5 files changed: 2 ins; 31 del; 6 mod

8300929: Avoid unnecessary array fill after creation in java.awt.image

Reviewed-by: attila, serb, aivanov

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

PR: https://git.openjdk.org/jdk/pull/12147


From psadhukhan at openjdk.org  Fri Feb  3 06:56:26 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 06:56:26 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v11]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <tVVi4h8GZo30TcEqTIckXxrzhv8C4v7PUT0rLvE1G78=.6d81f151-d463-41c1-8d80-4bd809977bef@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Add listener condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/76b02ea3..43922dca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=09-10

  Stats: 30 lines in 1 file changed: 28 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb  3 07:27:39 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 07:27:39 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v12]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <2z5m8u2BleMW4hOkxTcc4wwfREsM7X84lgbB9wE62oc=.da7a390f-4e18-46b8-846a-cf513ff650cc@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  jcheck fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/43922dca..cfae6062

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=10-11

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

PR: https://git.openjdk.org/jdk/pull/11940


From pminborg at openjdk.org  Fri Feb  3 07:28:02 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 3 Feb 2023 07:28:02 GMT
Subject: Integrated: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes
In-Reply-To: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
Message-ID: <zkfy8mHlUXx8B-5DZowdBEs4bzU-WOXxqc5fj2hphIQ=.35082180-960b-4001-9525-f49c175ebb5a@github.com>

On Wed, 25 Jan 2023 16:39:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
> 
> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.

This pull request has now been integrated.

Changeset: b504c941
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b504c9411e4a7a93e07a340a5d32a5ca9764a006
Stats:     373 lines in 6 files changed: 95 ins; 144 del; 134 mod

8300235: Use VarHandle access in Image(Input | Output)StreamImpl classes

Reviewed-by: rriggs

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

PR: https://git.openjdk.org/jdk/pull/12204


From alanb at openjdk.org  Fri Feb  3 07:40:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Feb 2023 07:40:00 GMT
Subject: RFR: 8300235: Use VarHandle access in Image(Input |
 Output)StreamImpl classes [v4]
In-Reply-To: <ViV_w-br_doi4-b5zLEUNoco0hH-5OOIDGMZVCHIRsU=.149b260e-a50c-4c22-8782-ddb1c29ec1bd@github.com>
References: <PPJBgKqkFFPV_e0GALCKfL3IXCw162qaY0IRWw4S0-M=.e118bdd0-f7b4-4765-9fba-5206ee264f7f@github.com>
 <ViV_w-br_doi4-b5zLEUNoco0hH-5OOIDGMZVCHIRsU=.149b260e-a50c-4c22-8782-ddb1c29ec1bd@github.com>
Message-ID: <A2az7mf95jU2mvmYG9AXL7Mj46BbqqKgTanlzNVFrso=.901a636a-7b28-45eb-9b1a-b2ad641d747d@github.com>

On Thu, 2 Feb 2023 19:29:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests improving performance by using the newly introduced class `jdk.internal.util.ByteArray` to improve packing/unpacking operations.
>> 
>> The PR also proposes adding a `ByteArrayLittleEndian` class for support for little endian packing/unpacking.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename to createLittleEndian

Do I read this correctly that the proposal is to have ByteArray and ByteArrayLittleEndian?

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

PR: https://git.openjdk.org/jdk/pull/12204


From psadhukhan at openjdk.org  Fri Feb  3 09:22:01 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 09:22:01 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
 <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
Message-ID: <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>

On Thu, 2 Feb 2023 21:35:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I haven't verified it, but I think it worked as it's stated: `done` is called first, then listeners are notified. According to the order of calls
>> 
>> https://github.com/openjdk/jdk/blob/b00b70c2400d28070d26630614a010bc52237827/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L310-L313
>> 
>> `SwingWorker.done` gets invoked first followed by `setState` which, in its turn, notifies the listeners.
>> 
>> At this time, as you pointed out, the order is reversed:
>> 
>> https://github.com/openjdk/jdk/blob/76b02ea3a8add954705d6df7f91f5896d141b02d/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L307-L308
>
>> It could be tested by flushing and blocking the EDT in the listener. That will allow us to check the order of events posted from the listener and from the "doneEDT".
> 
> Is flushing required?
> 
> Two `AtomicBoolean`s should do the job. EDT can't process two events simultaneously, one follows the other. So, `done` is expected to be called while both are `false`, and it sets its own flag to `true`; the listener should be called second, so its flag is `false` and `done`'s flag is `true`.
> 
> I'll leave it to Pransanta to figure out the details.

It seems the order of sequence is
listener->State.STARTED->doInBackground->listener->DONE->done

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

PR: https://git.openjdk.org/jdk/pull/11940


From tr at openjdk.org  Fri Feb  3 10:09:48 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 3 Feb 2023 10:09:48 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
Message-ID: <6cU8NzOqQ0JfnNfuCeWRWepTdtMjhMS6fotmcsDvNz4=.61aafb61-9575-4d21-b3f7-bd85308dab37@github.com>

On Thu, 2 Feb 2023 17:39:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
>> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
>> 
>> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
>> 
>> No regression test is added as it can be verified by SwingSet2 Tabledemo..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Fix works as expected.

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

Marked as reviewed by tr (Committer).

PR: https://git.openjdk.org/jdk/pull/12385


From abhiscxk at openjdk.org  Fri Feb  3 10:54:50 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 3 Feb 2023 10:54:50 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
Message-ID: <XYP8-eMnsA7EH-lRWvDUDa-43F0BQN1KT1A6YDp8mJw=.07f24f7f-c2ca-469c-95ee-2bf7fa113f95@github.com>

On Thu, 2 Feb 2023 17:39:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
>> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
>> 
>> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
>> 
>> No regression test is added as it can be verified by SwingSet2 Tabledemo..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Test verified with current fix.

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

Marked as reviewed by abhiscxk (Author).

PR: https://git.openjdk.org/jdk/pull/12385


From abhiscxk at openjdk.org  Fri Feb  3 11:36:53 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 3 Feb 2023 11:36:53 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color
In-Reply-To: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
Message-ID: <5vkNulrGTVh5EJcxRGtsdUTc7BQatCurj8X1U5AVyzI=.09200c32-aec5-43d7-89c8-40c3074a9fbe@github.com>

On Thu, 2 Feb 2023 16:33:06 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTest.java line 2:

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

Copyright year can be changed to 2023.

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTest.java line 118:

> 116:         hasNimbus = false;
> 117: 
> 118:         for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {

It seems the intention to run the test is in Nimbus LAF only. I think you can directly set the Nimbus LAF using `UIManager.setLookAndFeel("javax.swing.plaf.nimbus.NimbusLookAndFeel");` and can avoid the `for-loop, condition check` and `hasNimbus `variable.

To print the error message, LAF can be set within try-catch block.

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

PR: https://git.openjdk.org/jdk/pull/12390


From jwaters at openjdk.org  Fri Feb  3 11:47:34 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Feb 2023 11:47:34 GMT
Subject: RFR: 8301756: Missed constructor from 8301659
Message-ID: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>

8301659 has missed a reordered constructor defined inside libawt

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

Commit messages:
 - Reorder

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

PR: https://git.openjdk.org/jdk/pull/12405


From aivanov at openjdk.org  Fri Feb  3 12:23:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Feb 2023 12:23:55 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
 <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
 <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>
Message-ID: <BmWGzAsMYD3uO8GxInm-9MNHKzOB9Q5yCl269RhqN9I=.a8671024-3f4e-45bd-9f3e-2154d6febeeb@github.com>

On Fri, 3 Feb 2023 09:19:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It seems the order of sequence is listener->State.STARTED->doInBackground->listener->DONE->done

Yes, but the different order is specified: listener(STARTED) -> doInBackground -> done -> listener(DONE).

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb  3 12:33:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 12:33:58 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <BmWGzAsMYD3uO8GxInm-9MNHKzOB9Q5yCl269RhqN9I=.a8671024-3f4e-45bd-9f3e-2154d6febeeb@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
 <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
 <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>
 <BmWGzAsMYD3uO8GxInm-9MNHKzOB9Q5yCl269RhqN9I=.a8671024-3f4e-45bd-9f3e-2154d6febeeb@github.com>
Message-ID: <tj7oXDRuT8PgjJEAHt8bLT8BCRA-S4oeukYjgODQLSc=.2d009358-9b1c-4273-bb45-2a71328ec694@github.com>

On Fri, 3 Feb 2023 12:20:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It seems the order of sequence is
>> listener->State.STARTED->doInBackground->listener->DONE->done
>
>> It seems the order of sequence is listener->State.STARTED->doInBackground->listener->DONE->done
> 
> Yes, but the different order is specified: listener(STARTED) -> doInBackground -> done -> listener(DONE).

But then it will violate
https://github.com/openjdk/jdk/blob/810c8a271b4524ae776e2306ef699e04a7d145a2/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb  3 13:10:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Feb 2023 13:10:59 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <tj7oXDRuT8PgjJEAHt8bLT8BCRA-S4oeukYjgODQLSc=.2d009358-9b1c-4273-bb45-2a71328ec694@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
 <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
 <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>
 <BmWGzAsMYD3uO8GxInm-9MNHKzOB9Q5yCl269RhqN9I=.a8671024-3f4e-45bd-9f3e-2154d6febeeb@github.com>
 <tj7oXDRuT8PgjJEAHt8bLT8BCRA-S4oeukY
 jgODQLSc=.2d009358-9b1c-4273-bb45-2a71328ec694@github.com>
Message-ID: <0ZbxygIwSrtMb9n4Bm3DI1FpaUi_oNq2LIoVc9NyzFE=.1b52621f-14a5-4eb8-ab2f-c6e3d6954b98@github.com>

On Fri, 3 Feb 2023 12:31:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>>> It seems the order of sequence is listener->State.STARTED->doInBackground->listener->DONE->done
>> 
>> Yes, but the different order is specified: listener(STARTED) -> doInBackground -> done -> listener(DONE).
>
> But then it will violate
> https://github.com/openjdk/jdk/blob/810c8a271b4524ae776e2306ef699e04a7d145a2/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293

Hm? not really, state will transition to `DONE` after `doInBackground` is finished.

In fact, it'll happen soon enough: `doneEDT` will schedule execution of `done` on EDT and exit. Then the state will change to `DONE`. Yet listeners are notified on EDT, to this notification will also be scheduled to run on EDT.

Very much likely that the state is `DONE` when `done` is executed but it's not guaranteed.

---

The specification isn't clear, and some parts somewhat contradict each other. Logically, the state should transition to `DONE` as soon as `doInBackground` completes. Then both `done` method and listeners are called when the state is `DONE` that is *the background work is complete*.

Yet as it's specified now, the `done` method is called while the state is still `STARTED`. This kind of implies calling `get` may block because the result of computation may not be available yet. However, it's not the case: `get` never blocks if called from `done`: it either returns the result or throws `CancellationException`.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb  3 13:21:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Feb 2023 13:21:55 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v12]
In-Reply-To: <2z5m8u2BleMW4hOkxTcc4wwfREsM7X84lgbB9wE62oc=.da7a390f-4e18-46b8-846a-cf513ff650cc@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <2z5m8u2BleMW4hOkxTcc4wwfREsM7X84lgbB9wE62oc=.da7a390f-4e18-46b8-846a-cf513ff650cc@github.com>
Message-ID: <srh7r5QEE9uAQtkLC2WOzROs1sTqQ9nPFyAxaCVY2pk=.f4412d15-9397-4bb8-8b80-15372798aadb@github.com>

On Fri, 3 Feb 2023 07:27:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck fix

The more I think about it, the more I'm inclined towards this change may be unnecessary at all. Yet the spec needs to be updated.

Consider the following scenario. The user starts a long running operation, so `doInBackground` is being executed. It may block access to UI and show the progress. Then they decide they don't to wait any more, so they cancel the operation by clicking *Cancel* button the UI which calls `cancel(true)` on `SwingWorker`.

The thread that runs `doInBackground` is interrupted. It may not exit yet but *does it matter?*

>From the user's point of view, the operation is already cancelled. That fact that the background thread needs to perform some clean-up actions is irrelevant.

>From the developer's point of view, it does matter. It depends on what actions are valid on this instance of `SwingWorker`. Until `doInBackground` finishes, a resource may still be busy while it performs its clean-up.

Can the clean-up be run in background too? There's no univocal answer to this question: in some cases, it can; in other cases, it cannot.

Thus, with the current approach in this fix, `SwingWorker` provides stronger guarantees which are stated in the spec that `done` is called only after `doInBackground` finishes whether it's cancelled or not.

Before this fix, the guarantee was that the call to `get` doesn't block when `done` is called or when the listeners are notified about the state `DONE`.

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb  3 13:51:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 13:51:56 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v12]
In-Reply-To: <2z5m8u2BleMW4hOkxTcc4wwfREsM7X84lgbB9wE62oc=.da7a390f-4e18-46b8-846a-cf513ff650cc@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <2z5m8u2BleMW4hOkxTcc4wwfREsM7X84lgbB9wE62oc=.da7a390f-4e18-46b8-846a-cf513ff650cc@github.com>
Message-ID: <_1_i2pSRtkpXy0duU5ZOGNpGXj8x8QX4Di40X3jix40=.70cc3550-e6a2-4074-8df0-6a7ec6879a7b@github.com>

On Fri, 3 Feb 2023 07:27:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck fix

I think we should update the wording alongside this fix like this


  * {@code state} property change to {@code StateValue.STARTED}.  After the
- * {@code doInBackground} method is finished the {@code done} method is
- * executed.  Then {@code SwingWorker} notifies any {@code PropertyChangeListeners}
- * about the {@code state} property change to {@code StateValue.DONE}.
+ * {@code doInBackground} method is finished, then
+ * {@code SwingWorker} notifies any {@code PropertyChangeListeners}
+ *  about the {@code state} property change to {@code StateValue.DONE}, then {@code done} method is
+ *  executed.


To me, when `doInBackground `is finished, SwingWorker's job is done and so the STATE should be changed to DONE which is as per spec already mentioned earlier, and then it will call user's `done `method spec of which just says it will be executed `"after the {@code doInBackground} method is finished." ` which will still be valid.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb  3 13:57:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Feb 2023 13:57:57 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v12]
In-Reply-To: <2z5m8u2BleMW4hOkxTcc4wwfREsM7X84lgbB9wE62oc=.da7a390f-4e18-46b8-846a-cf513ff650cc@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <2z5m8u2BleMW4hOkxTcc4wwfREsM7X84lgbB9wE62oc=.da7a390f-4e18-46b8-846a-cf513ff650cc@github.com>
Message-ID: <h_1aP439Ys0E2fs1AQvB5pYhw6AilB7Lx6gacSe5OBE=.531e0dc6-8633-4b6f-a1c1-21a2a9afcc9b@github.com>

On Fri, 3 Feb 2023 07:27:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck fix

Yeah, I totally agree. It makes more sense to me this way. But it requires a CSR.

> ```
>   * {@code state} property change to {@code StateValue.STARTED}.  After the
> + * {@code doInBackground} method is finished, ~~then~~
> + * {@code SwingWorker} notifies any {@code PropertyChangeListeners}
> + *  about the {@code state} property change to {@code StateValue.DONE}, then {@code done} method is
> + *  executed.
> ```

Remove the first *?then?*. Maybe re-flow the text. Other than that, it looks good and it's consistent to the spec of `DONE`.

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb  3 14:13:34 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 14:13:34 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v13]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <OZNhKFK-aQRDBye3AE_6SqkeC_edGS0rTn_GyyqM5Ug=.117e492d-bb7e-40f4-ac7e-c99861975677@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Spec wording modified

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/cfae6062..7f7bda7c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/11940


From jwaters at openjdk.org  Fri Feb  3 15:18:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Feb 2023 15:18:27 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

Julian Waters 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 comments
 - Partial Revert
 - sspi.cpp
 - Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/9c74387b..6b17f624

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=00-01

  Stats: 10119 lines in 311 files changed: 3838 ins; 2509 del; 3772 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

PR: https://git.openjdk.org/jdk/pull/12305


From prr at openjdk.org  Fri Feb  3 16:31:05 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Feb 2023 16:31:05 GMT
Subject: Integrated: 8300891: Deprecate for removal
 javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)
In-Reply-To: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
References: <tEURQVW-RurY4wZAyY5yEZgF2qQsEvtfcOmOL4DVPv4=.618e1bf3-35af-4ab8-b0cf-dde75bd8d678@github.com>
Message-ID: <5NIqUVIk36TbY91CziVQXKVzIwveauQmQqFSDeQ602k=.a42102a7-4047-4e87-9864-3c7befdb26b5@github.com>

On Tue, 24 Jan 2023 23:29:58 GMT, Phil Race <prr at openjdk.org> wrote:

> SynthLookAndFeel.load(URL) is problematic because applications need to trust the URL.
> As documented in the bug report there are alternative mechanisms and JDK itself has not used this for the two Synth based L&Fs : Nimbus and GTK.
> So deprecating - for removal - and adding warnings now in the docs is appropriate.

This pull request has now been integrated.

Changeset: 5962226c
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5962226cc33de047946aca6522f020c97d663d2f
Stats:     24 lines in 2 files changed: 24 ins; 0 del; 0 mod

8300891: Deprecate for removal javax.swing.plaf.synth.SynthLookAndFeel.load(URL url)

Reviewed-by: serb, aivanov, kizune, psadhukhan

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

PR: https://git.openjdk.org/jdk/pull/12175


From prr at openjdk.org  Fri Feb  3 17:02:53 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Feb 2023 17:02:53 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
Message-ID: <hzyCqVM_gaNYiZKrZddzyGEYtDTv62ZmkoaYVAen5GE=.b0c92c57-5e2e-40e2-a2fe-d00dd3b255d1@github.com>

On Thu, 12 Jan 2023 06:14:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec wording

I still am having problems fully understanding this.
(1) Is it correct that in cases like this there's no Basic**UI registered instead ?
(2) If Metal is registering just the UI classes used by *all* L&Fs, how on earth can it know that ?
   Suppose I wrote another Theme and it did not use one of the UI classes, would you really
need to update this code to stop registering it and then update every other theme to register it ?

It just does not make sense to me.

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

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Fri Feb  3 17:15:50 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 17:15:50 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
Message-ID: <bcmjxmDk4NzIZ15Hc0fxKfuMhMTwwNjgAiwv3Bl5Y48=.d604b810-758c-4440-9fac-8630ba88651f@github.com>

On Thu, 12 Jan 2023 06:14:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec wording

(1) This is an unique case..Normally, if there is no entry in `MetalLookAndFeel.initClassDefaults`, it means corresponding `Basic**UI class` will be used. However, in this case `MetalMenuBarUI `does not have entry in `MetalLookAndFeel.initClassDefaults` rather it is registered in `OceanTheme`, so it will not use `BasicMenuBarUI `even though `BasicMenuBarUI `is present
(2) If the Metal**UI class is to be used by a particular theme, then yes it seems it needs to be registered in that theme and not in MetalLookAndFeel.initClassDefaults

If any Metal**UI is registered in MetalLookAndFeel.initClassDefaults, then it means that Metal**UI will be used by all Metal Themes

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

PR: https://git.openjdk.org/jdk/pull/11646


From honkar at openjdk.org  Fri Feb  3 17:26:22 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 3 Feb 2023 17:26:22 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v3]
In-Reply-To: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
Message-ID: <3y2rUWBiNMz68tvWWzJzFB_2NSdsZsygQXyRL2i8cpg=.9ac1c098-ddaa-46b5-acc8-6274ec0a9b59@github.com>

> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
> 
> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.

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

  minor change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12391/files
  - new: https://git.openjdk.org/jdk/pull/12391/files/a0e8b29e..ab1e6e79

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12391


From honkar at openjdk.org  Fri Feb  3 17:29:51 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 3 Feb 2023 17:29:51 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
Message-ID: <qvyqP0Xzq1vu5lW8XC49Gg_hoUQK3QoL9W3dZknyPYs=.f1fef3b9-2ca7-4c4f-afb9-f76c2c260572@github.com>

On Thu, 2 Feb 2023 17:39:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
>> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
>> 
>> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
>> 
>> No regression test is added as it can be verified by SwingSet2 Tabledemo..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

Copyright year for SynthTableUI requires an update.

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

PR: https://git.openjdk.org/jdk/pull/12385


From prr at openjdk.org  Fri Feb  3 17:35:56 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Feb 2023 17:35:56 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <bcmjxmDk4NzIZ15Hc0fxKfuMhMTwwNjgAiwv3Bl5Y48=.d604b810-758c-4440-9fac-8630ba88651f@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
 <bcmjxmDk4NzIZ15Hc0fxKfuMhMTwwNjgAiwv3Bl5Y48=.d604b810-758c-4440-9fac-8630ba88651f@github.com>
Message-ID: <QEPsZGaXGJb29G_pG4muHj6GYVQLblpt1Os8KGLt1cw=.799370dc-af63-4299-a959-fb802d26b51b@github.com>

On Fri, 3 Feb 2023 17:12:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> (1) This is an unique case..Normally, if there is no entry in `MetalLookAndFeel.initClassDefaults`, it means corresponding `Basic**UI class` will be used. However, in this case `MetalMenuBarUI `does not have entry in `MetalLookAndFeel.initClassDefaults` rather it is registered in `OceanTheme`, so it will not use `BasicMenuBarUI `even though `BasicMenuBarUI `is present (2) If the Metal**UI class is to be used by a particular theme, then yes it seems it needs to be registered in that theme and not in MetalLookAndFeel.initClassDefaults
> 
> If any Metal**UI is registered in MetalLookAndFeel.initClassDefaults, then it means that Metal**UI will be used by all Metal Themes

On that latter point "really?" I think you mean they all *happen* to use it ?
That isn't the same thing as a specification or a "law" that they all DO use it.
Once again, what if I wrote a new Theme that did NOT use one of these ?

So  the situation is nearly un-specifiable in any satisfactory way.
Near as I can tell it actually amounts to 
"Since only one of the built-in themes use MetalMenuBarUI, the developer doing this work decided not to register it here, and let the single built-in theme that does, register it instead".

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

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Fri Feb  3 17:46:52 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 17:46:52 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
Message-ID: <g1T9LA3F-Oli27xDuDvjSxjTWSSVNKlw7w01FIkG7ho=.50a071e4-245b-4bb4-ba86-a0c8cce82c58@github.com>

On Thu, 12 Jan 2023 06:14:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec wording

I can only say what I see as per code so I am not sure if it is meant or designed to be that way
You might be right on the last statement. Since there are only one implemented Metal theme, I dont know for sure if it is meant to be or just done for convenience

If you are not sure, we can close it as "Wont fix"

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

PR: https://git.openjdk.org/jdk/pull/11646


From prr at openjdk.org  Fri Feb  3 17:58:54 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Feb 2023 17:58:54 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <g1T9LA3F-Oli27xDuDvjSxjTWSSVNKlw7w01FIkG7ho=.50a071e4-245b-4bb4-ba86-a0c8cce82c58@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
 <g1T9LA3F-Oli27xDuDvjSxjTWSSVNKlw7w01FIkG7ho=.50a071e4-245b-4bb4-ba86-a0c8cce82c58@github.com>
Message-ID: <VnI2Kv9MEbr1je7coZjgzhknljJg4JMmSfq9UfcuOTU=.dd800e16-d934-4b6b-9ce0-6848ff66f1b7@github.com>

On Fri, 3 Feb 2023 17:42:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I can only say what I see as per code so I am not sure if it is meant or designed to be that way You might be right on the last statement. Since there are only one implemented Metal theme, I dont know for sure if it is meant to be or just done for convenience
> 
> If you are not sure, we can close it as "Wont fix"

And leave it that the implementation contradicts the specification ?

And If I am writing a new Theme do I really have to know which UI classes are always installed ? Its crazy.

Let's go back to the beginning.
What would happen if you DID register all Metal*UI classes for all themes ?
Even if it isn't used, what would go wrong ?

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

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Fri Feb  3 18:03:52 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Feb 2023 18:03:52 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <VnI2Kv9MEbr1je7coZjgzhknljJg4JMmSfq9UfcuOTU=.dd800e16-d934-4b6b-9ce0-6848ff66f1b7@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
 <g1T9LA3F-Oli27xDuDvjSxjTWSSVNKlw7w01FIkG7ho=.50a071e4-245b-4bb4-ba86-a0c8cce82c58@github.com>
 <VnI2Kv9MEbr1je7coZjgzhknljJg4JMmSfq9UfcuOTU=.dd800e16-d934-4b6b-9ce0-6848ff66f1b7@github.com>
Message-ID: <pK8buQ4W_ErNIgtBuQ481NAl3RPvPOw2QoMl98UBSZc=.6618a28b-ed6b-4146-92a8-69d3dbe5bb6f@github.com>

On Fri, 3 Feb 2023 17:56:17 GMT, Phil Race <prr at openjdk.org> wrote:

> What would happen if you DID register all Metal*UI classes for all themes ?
> Even if it isn't used, what would go wrong ?

Well, I did try registering MetalMenuBarUI in MetalLookAndFeel.initClassDefaults (as you can see in the 1st iteration of this PR) and I do not see any regression in jtreg tests. Then it was pointed out to me that the spec, instead, need to be updated to specify it is only for OceanTheme

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

PR: https://git.openjdk.org/jdk/pull/11646


From prr at openjdk.org  Fri Feb  3 18:11:56 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Feb 2023 18:11:56 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
Message-ID: <1d2W0Lz8GsavwyVRvEFk4yDlhtvUrN2PCRpmu4CxWtM=.cdc2e940-3ea5-45cb-81a3-bde501228461@github.com>

On Thu, 12 Jan 2023 06:14:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update spec wording

These words - "This class is only appropriate for Ocean. The spec needs to be updated to mention this."

WHY can no other Theme use it ? Is there a reason ?
I think the comment does not have enough backing explanation to be simply followed blindly.

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

PR: https://git.openjdk.org/jdk/pull/11646


From aivanov at openjdk.org  Fri Feb  3 19:37:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Feb 2023 19:37:53 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
Message-ID: <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>

On Fri, 3 Feb 2023 15:18:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters 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 comments
>  - Partial Revert
>  - sspi.cpp
>  - Comments

Except for the change in `sspi.cpp`, it looks good to me.

src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 31:

> 29: // This library can be built directly with the following command:
> 30: //   cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp
> 31: //      -link -dll -out:sspi_bridge.dll

I think the backslash `` should remain there: it's a command line and `` is used to wrap the long line.

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12305


From dnguyen at openjdk.org  Fri Feb  3 19:51:14 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 3 Feb 2023 19:51:14 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v2]
In-Reply-To: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
Message-ID: <M2nJIpXa4EMRxlkUMrvoxkAGiF5w_rS7UeIsYd7JQVI=.fffe3803-4a3c-42e7-bdb3-00896a36e792@github.com>

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12390/files
  - new: https://git.openjdk.org/jdk/pull/12390/files/5769ffe5..d586b750

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Fri Feb  3 19:56:18 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 3 Feb 2023 19:56:18 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v3]
In-Reply-To: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
Message-ID: <sZOcdXuQ6PM5VhZK__K5_7DPOMNfZ-jx6m891_ldtCo=.8e9dee5d-b0e3-4ec2-9031-8df7cf6f728b@github.com>

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

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

  Simplify Nimbus LAF check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12390/files
  - new: https://git.openjdk.org/jdk/pull/12390/files/d586b750..fa70b83f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Fri Feb  3 19:56:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 3 Feb 2023 19:56:19 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v3]
In-Reply-To: <5vkNulrGTVh5EJcxRGtsdUTc7BQatCurj8X1U5AVyzI=.09200c32-aec5-43d7-89c8-40c3074a9fbe@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <5vkNulrGTVh5EJcxRGtsdUTc7BQatCurj8X1U5AVyzI=.09200c32-aec5-43d7-89c8-40c3074a9fbe@github.com>
Message-ID: <yJ53PS9ocqrxmqYxi7njQ37V3YHImjQykoE0qdEDJdc=.e90525ef-ebba-49d6-8c99-91793b096b6e@github.com>

On Fri, 3 Feb 2023 11:33:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify Nimbus LAF check
>
> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, Oracle and/or its affiliates. All rights reserved.
> 
> Copyright year can be changed to 2023.

Updated

> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTest.java line 118:
> 
>> 116:         hasNimbus = false;
>> 117: 
>> 118:         for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) {
> 
> It seems the intention to run the test is in Nimbus LAF only. I think you can directly set the Nimbus LAF using `UIManager.setLookAndFeel("javax.swing.plaf.nimbus.NimbusLookAndFeel");` and can avoid the `for-loop, condition check` and `hasNimbus `variable.
> 
> To print the error message, LAF can be set within try-catch block.

Thanks for the suggestion. I made the change. I initially had this loop to test locally for all LAF's, but ended up using this test for Nimbus only as originally designed.

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

PR: https://git.openjdk.org/jdk/pull/12390


From achung at openjdk.org  Fri Feb  3 20:11:54 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 3 Feb 2023 20:11:54 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v4]
In-Reply-To: <So1sQBy1ufhszMW8Kn-uIPikvpP55Ew1BWApyrt_3NI=.37c8dd7c-7e44-41a9-96be-323cb563222f@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <faAg_l3mXZDdEBAJHX4vR966zDgWXgEaTZsISNZtUeY=.f2f11807-9105-47b5-bc93-9f82f24e974e@github.com>
 <So1sQBy1ufhszMW8Kn-uIPikvpP55Ew1BWApyrt_3NI=.37c8dd7c-7e44-41a9-96be-323cb563222f@github.com>
Message-ID: <i096bIbQD3PwqFlV7V8ytXql-NYqAk_69MVQFcPeAjQ=.324c2bab-834a-48b7-9ec2-68fb2764af15@github.com>

On Wed, 1 Feb 2023 23:23:13 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
>>  - added debug statements
>>  - re-test
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
>>  - added robot wait to prevent mouse position from being calculated before robot finishes mouseMove
>
> test/jdk/java/awt/Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java line 97:
> 
>> 95: //            if (!Util.testBoundsColor(bounds, color, 5, 1000, robot)) {
>> 96: //                throw new RuntimeException(getErrorText("Robot.getPixelColor", i));
>> 97: //            }
> 
> Why was this commented out? And if it's commented out, isn't it better to just be removed? It still seems to pass with it included. 
> 
> I tested with the newest changes. It passes on my local machine running macOS Monterey 12.3.1 using dual monitors. The test does create a yellow frame on both monitors and the color check passes in the test. I ran the test 5 times locally without any failures.

Oops, this was for debugging purposes, let me remove this

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

PR: https://git.openjdk.org/jdk/pull/10363


From aivanov at openjdk.org  Fri Feb  3 20:13:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Feb 2023 20:13:59 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v3]
In-Reply-To: <3y2rUWBiNMz68tvWWzJzFB_2NSdsZsygQXyRL2i8cpg=.9ac1c098-ddaa-46b5-acc8-6274ec0a9b59@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
 <3y2rUWBiNMz68tvWWzJzFB_2NSdsZsygQXyRL2i8cpg=.9ac1c098-ddaa-46b5-acc8-6274ec0a9b59@github.com>
Message-ID: <VDvf5kevvU0B-rH4HuXPDpMV8XexxgB9BQdWFyRMj1w=.54b4579a-4dd6-4c30-acbc-94ac08012dac@github.com>

On Fri, 3 Feb 2023 17:26:22 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
>> 
>> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 239:

> 237: 
> 238:     @SuppressWarnings("serial")
> 239:     private abstract static sealed class AbstractMetalBorder

Suggestion:

    private abstract static sealed class AbstractMetalWindowBorder

or
Suggestion:

    private abstract static sealed class MetalWindowBorder

So that it's the class name is more specific: it applies only to window-like objects: Frame, Dialog and Internal Frame.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 255:

> 253:             SwingUtilities3.paintBorder(c, g,
> 254:                     x, y, w, h,
> 255:                     this::paintUnscaledBorder);

It's a matter of preference, however, I prefer the previous style where parameters are aligned after the opening parenthesis.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 272:

> 270:         protected abstract boolean isActive(Component c);
> 271: 
> 272:         protected abstract boolean isResizable(Component c);

What do you think if we declare these two abstract methods above `updateColors`? Or just `isActive` method?

It may help to understand the code inside `updateColors`.

It's not a strong suggestion.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 291:

> 289:                 //are positioned on the border
> 290:                 int midPoint = thickness / 2;
> 291:                 int stkWidth = clipRound(scaleFactor);

It's not part of this changeset, yet is possible to spell it out? When words spelled fully, like `strokeWidth`, they're easier to understand.

Maybe do it under a separate issue to make this one cleaner.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 359:

> 357:         }
> 358: 
> 359:         public void paintBorder(Component c, Graphics g, int x, int y,

Let's add `@Override`?

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 364:

> 362:         }
> 363: 
> 364:         public Insets getBorderInsets(Component c, Insets newInsets) {

Let's add @Override?

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 375:

> 373:      */
> 374:     @SuppressWarnings("serial") // Superclass is not serializable across versions
> 375:     static final class FrameBorder extends AbstractMetalBorder implements UIResource {

If the class isn't used anywhere but `MetalBorders` class, does it make sense to declare the class `private`? I think it does, it conveys that this class is used only here.

This applies to other classes too.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 396:

> 394:      */
> 395:     @SuppressWarnings("serial") // Superclass is not serializable across versions
> 396:     static sealed class DialogBorder

Probably `DialogBorder` should extend `FrameBorder` to inherit and re-use `isActive` and `isResizable` methods: they're the same in both classes.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 401:

> 399:             permits ErrorDialogBorder, QuestionDialogBorder, WarningDialogBorder {
> 400: 
> 401:         protected Color getActiveBackground() {

Either leave the opening brace on its own line it used to be, or update the style for the following methods as well.

test/jdk/javax/swing/plaf/metal/MetalBorders/ScaledMetalBorderTest.java line 167:

> 165: 
> 166:     private static void runTests(String windowType) throws InterruptedException,
> 167:                                                          InvocationTargetException {

Suggestion:

    private static void runTests(String windowType) throws InterruptedException,
                                                           InvocationTargetException {

Should they rather be aligned?

test/jdk/javax/swing/plaf/metal/MetalBorders/ScaledMetalBorderTest.java line 318:

> 316:         jDialog.setLayout(new GridBagLayout());
> 317:         jDialog.getContentPane().add(scale);
> 318:         jDialog.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);

Suggestion:

        jDialog.setDefaultCloseOperation(JDialog.DISPOSE_ON_CLOSE);

Would be more logical.

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

PR: https://git.openjdk.org/jdk/pull/12391


From achung at openjdk.org  Fri Feb  3 20:24:16 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 3 Feb 2023 20:24:16 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v5]
In-Reply-To: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
Message-ID: <2VwBZ7updndz-IQpRPzIMbCtigNqjiYR30iZX2REcWg=.ad216634-0a88-467e-9a78-bf7c87ed1c32@github.com>

> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete

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

  uncommented portion of test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10363/files
  - new: https://git.openjdk.org/jdk/pull/10363/files/ef1e22e0..af7dd626

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10363&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/10363


From achung at openjdk.org  Fri Feb  3 20:24:18 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 3 Feb 2023 20:24:18 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v4]
In-Reply-To: <So1sQBy1ufhszMW8Kn-uIPikvpP55Ew1BWApyrt_3NI=.37c8dd7c-7e44-41a9-96be-323cb563222f@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <faAg_l3mXZDdEBAJHX4vR966zDgWXgEaTZsISNZtUeY=.f2f11807-9105-47b5-bc93-9f82f24e974e@github.com>
 <So1sQBy1ufhszMW8Kn-uIPikvpP55Ew1BWApyrt_3NI=.37c8dd7c-7e44-41a9-96be-323cb563222f@github.com>
Message-ID: <2HFA6fqB1MJlcacT63Ov8llyMhJvluKtvVEL3U7soCY=.e77d9f02-10a1-4ada-ba17-ad22e80868cd@github.com>

On Wed, 1 Feb 2023 23:23:13 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Alisen Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
>>  - added debug statements
>>  - re-test
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8292588/MultiScreenLocationTest
>>  - added robot wait to prevent mouse position from being calculated before robot finishes mouseMove
>
> test/jdk/java/awt/Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java line 97:
> 
>> 95: //            if (!Util.testBoundsColor(bounds, color, 5, 1000, robot)) {
>> 96: //                throw new RuntimeException(getErrorText("Robot.getPixelColor", i));
>> 97: //            }
> 
> Why was this commented out? And if it's commented out, isn't it better to just be removed? It still seems to pass with it included. 
> 
> I tested with the newest changes. It passes on my local machine running macOS Monterey 12.3.1 using dual monitors. The test does create a yellow frame on both monitors and the color check passes in the test. I ran the test 5 times locally without any failures.

@DamonGuy can you double check that this portion of the test also passes on your machine?

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

PR: https://git.openjdk.org/jdk/pull/10363


From honkar at openjdk.org  Fri Feb  3 22:13:53 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 3 Feb 2023 22:13:53 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v3]
In-Reply-To: <VDvf5kevvU0B-rH4HuXPDpMV8XexxgB9BQdWFyRMj1w=.54b4579a-4dd6-4c30-acbc-94ac08012dac@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
 <3y2rUWBiNMz68tvWWzJzFB_2NSdsZsygQXyRL2i8cpg=.9ac1c098-ddaa-46b5-acc8-6274ec0a9b59@github.com>
 <VDvf5kevvU0B-rH4HuXPDpMV8XexxgB9BQdWFyRMj1w=.54b4579a-4dd6-4c30-acbc-94ac08012dac@github.com>
Message-ID: <l6App-tx9TJTqNZbOkQLDlfvGoBkofQdbDdeIlopuGI=.ebd38164-9718-4a9e-b09d-87fb9b597422@github.com>

On Fri, 3 Feb 2023 19:51:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor change
>
> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 375:
> 
>> 373:      */
>> 374:     @SuppressWarnings("serial") // Superclass is not serializable across versions
>> 375:     static final class FrameBorder extends AbstractMetalBorder implements UIResource {
> 
> If the class isn't used anywhere but `MetalBorders` class, does it make sense to declare the class `private`? I think it does, it conveys that this class is used only here.
> 
> This applies to other classes too.

Border classes are used within MetalLookAndFeel.java hence cannot be made private.

> src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 396:
> 
>> 394:      */
>> 395:     @SuppressWarnings("serial") // Superclass is not serializable across versions
>> 396:     static sealed class DialogBorder
> 
> Probably `DialogBorder` should extend `FrameBorder` to inherit and re-use `isActive` and `isResizable` methods: they're the same in both classes.

Since `isResizable` has to be overridden in this case as well, retaining the original class hierarchy.

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

PR: https://git.openjdk.org/jdk/pull/12391


From duke at openjdk.org  Fri Feb  3 22:33:49 2023
From: duke at openjdk.org (SWinxy)
Date: Fri, 3 Feb 2023 22:33:49 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v2]
In-Reply-To: <KiSK3WRE-PpbRkZqG-LhokL6HzWISYevRTWMmM2vFsU=.e0c3b752-82df-475e-98c9-79dc4ddc5311@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <KwuZH3CQlUiklf-h_yzbB1RzoXACnqXNjWX4RZjGCI0=.5651d65a-391c-4588-9037-4d78d2ae357e@github.com>
 <YhS-pkykLDaNGlAiB-YDNyUkVYk-GceGszx7zvt6_aQ=.ad2efd92-6c58-4c45-9a54-6dad14eb42b3@github.com>
 <0xRhqnSHTdlFswnkxX4GWQQAC_mB8pZXJoJEXuaszCE=.5b6e987a-40fd-4089-bddb-b79845ac212f@github.com>
 <KiSK3WRE-PpbRkZqG-LhokL6HzWISYevRTWMmM2vFsU=.e0c3b752-82df-475e-98c9-79dc4ddc5311@github.com>
Message-ID: <WfAepjS41o7yNXawcdCuT5dya9Vm4yM_Ku-NLIcXXwQ=.68f74d8c-ce0e-4127-b7ad-5986e03b0ff6@github.com>

On Mon, 19 Dec 2022 21:43:26 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> This change cause 23 test cases to fail across the platforms:
>> 
>> So I thought we'd got past the testing since a CSR was proposed. The CSR should have waited.
>> 
>>> 
>>> * `sanity/client/SwingSet/src/SwingSet2DemoTest.java`;
>>> * `javax/swing/GraphicsConfigNotifier/StalePreferredSize.java`;
>>> * two closed tests.
>>> 
>>> **One JCK test** fails; from a quick look, it's because the font is now uninstalled where it wasn't previously.
>> 
>> So all the test failures are blocker problem .. @aivanov-jdk, do any of the jtreg test failures characterise the JCK failure ?
>> Meaning something the submitter can use as a proxy to understand the problem
>> Do these failures suggest that there's a good reason why these fonts and colors are not installed ? 
>> Or do we have 23 (!) tests which have an assumption they probably shouldn't have ?
>> Possible, but in that case, would apps have the same assumptions ?
>
>> One JCK test fails; from a quick look, it's because the font is now uninstalled where it wasn't previously.
> 
> I confirmed it's a test problem. The JCK test needs to be updated. Details are in a confidential comment in JBS.
> 
> Do I need to submit a bug against JCK?
> 
> 
>> do any of the jtreg test failures characterise the JCK failure ?
> 
> The failure of `javax/swing/GraphicsConfigNotifier/StalePreferredSize.java` may be related. The test fails for `JLabel`.
> 
> The test calls `SwingUtilities.updateComponentTreeUI(frame)` and expects the preferred size doesn't change. Yet it does change.
> 
> The failure in `sanity/client/SwingSet/src/SwingSet2DemoTest.java` is also related. It fails because of timeout where a font on a component (`JButton` presumably) doesn't change to _bold_ after selecting **Theme** ? **Font** ? **Bold** in the menu. Selecting this menu item results in `SwingUtilities.updateComponentTreeUI(frame)` being called to update the look and feel properties of all the components.
> 
> 
> As for the closed test failure, it doesn't look related. A component being painted is null. It shouldn't happen.

I'm really not sure how to fix these. I've tried digging into the tests. It looks like uninstalling the fonts from the components screws with other parts of Swing, specifically that delegates are calling `getFont` after they've been uninstalled? At least that's my guess. I'm unsure how to continue. @aivanov-jdk, could you please help me with this?

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

PR: https://git.openjdk.org/jdk/pull/10565


From dnguyen at openjdk.org  Fri Feb  3 22:42:50 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 3 Feb 2023 22:42:50 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v5]
In-Reply-To: <2VwBZ7updndz-IQpRPzIMbCtigNqjiYR30iZX2REcWg=.ad216634-0a88-467e-9a78-bf7c87ed1c32@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <2VwBZ7updndz-IQpRPzIMbCtigNqjiYR30iZX2REcWg=.ad216634-0a88-467e-9a78-bf7c87ed1c32@github.com>
Message-ID: <HkZyjWunhrowCTIhr9zXaJtDAAeGm1lEMYDYL5TdIyo=.518f9002-49a9-44ef-b1e6-13210b878716@github.com>

On Fri, 3 Feb 2023 20:24:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncommented portion of test

Marked as reviewed by dnguyen (Author).

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

PR: https://git.openjdk.org/jdk/pull/10363


From dnguyen at openjdk.org  Fri Feb  3 22:42:51 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 3 Feb 2023 22:42:51 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v2]
In-Reply-To: <-S1P8rII2nr7IZWPLVrIRSbmcTdBujDX_5eto_GUUxM=.a2b606ae-8dd9-4942-8f92-b536a8154ff6@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <_F66GasxdremocPjHV9uOyJLZQy83LD3KZ7FJFgtPU4=.f8e837d5-8ebc-4f10-8849-47334cb213d9@github.com>
 <_ghd81JZBoqpumCfJYCRJBx2If1fVThQ3Djv7l4NSjg=.e73fdc48-6100-4a73-8cb2-8fe2df6c0d40@github.com>
 <-S1P8rII2nr7IZWPLVrIRSbmcTdBujDX_5eto_GUUxM=.a2b606ae-8dd9-4942-8f92-b536a8154ff6@github.com>
Message-ID: <f1sAemrQOD77uss-O673HGruBlWt2Adu9lmq2CLQiWI=.d54d270f-ede5-461c-9744-96c8a345ff9e@github.com>

On Thu, 26 Jan 2023 00:16:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

> > The suggested change does fix the mouse pointer issue.
> > However, the test still fails for me:
> > ```
> > Exception in thread "main" java.lang.RuntimeException: Robot.getPixelColor test failed on Screen #1!
> > 	at MultiScreenLocationTest.main(MultiScreenLocationTest.java:98)
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Is it possible to add diagnostic information?
> > If `moveMove` fails, one may want to see what the coordinates are, what the expected coordinates are and what the bounds of the current screen are.
> > If `getPixelColor` fails, what is the color of the pixel and what is the expected color?
> > These changes will be helpful for you while you debugging and updating the test as well as for anyone who has to deal with the test later.
> 
> Sure, I can add that. What fixed the issue for me for the latter two issues was setting the color profile of the second monitor in the system preferences. Under Display > Color I set Display Profile to be sRGB IEC61966-2.1 on the second monitor and the test then passes.

My test initially failed as well, but after changing my 2nd monitor's color profile as described, it does pass.

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

PR: https://git.openjdk.org/jdk/pull/10363


From dnguyen at openjdk.org  Fri Feb  3 22:42:54 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 3 Feb 2023 22:42:54 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v4]
In-Reply-To: <2HFA6fqB1MJlcacT63Ov8llyMhJvluKtvVEL3U7soCY=.e77d9f02-10a1-4ada-ba17-ad22e80868cd@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <faAg_l3mXZDdEBAJHX4vR966zDgWXgEaTZsISNZtUeY=.f2f11807-9105-47b5-bc93-9f82f24e974e@github.com>
 <So1sQBy1ufhszMW8Kn-uIPikvpP55Ew1BWApyrt_3NI=.37c8dd7c-7e44-41a9-96be-323cb563222f@github.com>
 <2HFA6fqB1MJlcacT63Ov8llyMhJvluKtvVEL3U7soCY=.e77d9f02-10a1-4ada-ba17-ad22e80868cd@github.com>
Message-ID: <-TJIBDZMMYd0T6GbZLPwTR2UouQ1uK4QJZrfH0WL8UM=.cb4e0766-fad6-4c7e-b3b9-1b19645759be@github.com>

On Fri, 3 Feb 2023 20:20:24 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/java/awt/Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java line 97:
>> 
>>> 95: //            if (!Util.testBoundsColor(bounds, color, 5, 1000, robot)) {
>>> 96: //                throw new RuntimeException(getErrorText("Robot.getPixelColor", i));
>>> 97: //            }
>> 
>> Why was this commented out? And if it's commented out, isn't it better to just be removed? It still seems to pass with it included. 
>> 
>> I tested with the newest changes. It passes on my local machine running macOS Monterey 12.3.1 using dual monitors. The test does create a yellow frame on both monitors and the color check passes in the test. I ran the test 5 times locally without any failures.
>
> @DamonGuy can you double check that this portion of the test also passes on your machine?

I checked again with `testBoundsColor` conditional commented and uncommented, and both passed with a dual monitor setup on macOS Monterey 12.3.1

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

PR: https://git.openjdk.org/jdk/pull/10363


From honkar at openjdk.org  Fri Feb  3 22:43:22 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 3 Feb 2023 22:43:22 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v4]
In-Reply-To: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
Message-ID: <M7gsh2iBq4e1-FiOlDnZhVtcugPt-p4Es9IX2oWbVD0=.d9739dc1-686f-40e1-bcc0-aabebbf33bcd@github.com>

> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
> 
> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.

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:

 - review changes: AbstractMetalWindowBorder, strokeWidth rename
 - Merge branch 'master' into MetalBorderRefactor_8294484
 - minor change
 - removed unused import
 - added updateColor(), isActive() to MetalBorder
 - test summary changes
 - deleted InternalFrameBorderTest
 - moved corner var to AbstractMetalBorder
 - sealed abstract class, record changes
 - initial commit, consolidated test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12391/files
  - new: https://git.openjdk.org/jdk/pull/12391/files/ab1e6e79..4be01e84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=02-03

  Stats: 10696 lines in 326 files changed: 4314 ins; 2543 del; 3839 mod
  Patch: https://git.openjdk.org/jdk/pull/12391.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12391/head:pull/12391

PR: https://git.openjdk.org/jdk/pull/12391


From jwaters at openjdk.org  Sat Feb  4 07:45:52 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Feb 2023 07:45:52 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
Message-ID: <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>

On Fri, 3 Feb 2023 19:32:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters 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 comments
>>  - Partial Revert
>>  - sspi.cpp
>>  - Comments
>
> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 31:
> 
>> 29: // This library can be built directly with the following command:
>> 30: //   cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp
>> 31: //      -link -dll -out:sspi_bridge.dll
> 
> I think the backslash `` should remain there: it's a command line and `` is used to wrap the long line.

I did think about that too when I first saw it, but the command this is often run from is the Windows CMD, which does not accept `` to escape to the next line. MSYS bash does not have the required environment set up outside of configure time to run `cl` either, but I have not tested with WSL yet. I suppose one could do the complicated setup required to be able to run this from the winenv provided bash, but that seems like a lot of hassle, enough that to me someone trying to compile sspi_bridge.dll by itself wouldn't really bother with the process. On top of that cl.exe will actually interpret the backslash as the literal object file `.o` for some weird reason. I've already pinged the original author of the file @wangweij above to ask for guidance on this as such

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

PR: https://git.openjdk.org/jdk/pull/12305


From ysuenaga at openjdk.org  Sat Feb  4 09:49:28 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sat, 4 Feb 2023 09:49:28 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
Message-ID: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>

C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.

* HotSpot
    * stubGenerator_x86_64_poly.cpp
    * elfFile.hpp
* libfontmanager
    * hb.hh
* libfreetype
    * afblue.c

I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

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

Commit messages:
 - 8301820: C4819 warnings were reported on Windows

Changes: https://git.openjdk.org/jdk/pull/12427/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12427&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301820
  Stats: 56 lines in 3 files changed: 0 ins; 0 del; 56 mod
  Patch: https://git.openjdk.org/jdk/pull/12427.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12427/head:pull/12427

PR: https://git.openjdk.org/jdk/pull/12427


From weijun at openjdk.org  Sat Feb  4 13:39:54 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 4 Feb 2023 13:39:54 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
Message-ID: <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>

On Sat, 4 Feb 2023 07:42:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.security.jgss/windows/native/libsspi_bridge/sspi.cpp line 31:
>> 
>>> 29: // This library can be built directly with the following command:
>>> 30: //   cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp
>>> 31: //      -link -dll -out:sspi_bridge.dll
>> 
>> I think the backslash `` should remain there: it's a command line and `` is used to wrap the long line.
>
> I did think about that too when I first saw it, but the command this is often run from is the Windows CMD, which does not accept `` to escape to the next line. MSYS bash does not have the required environment set up outside of configure time to run `cl` either, but I have not tested with WSL yet. I suppose one could do the complicated setup required to be able to run this from the winenv provided bash, but that seems like a lot of hassle, enough that to me someone trying to compile sspi_bridge.dll by itself wouldn't really bother with the process. On top of that cl.exe will actually interpret the backslash as the literal object file `.o` for some weird reason. I've already pinged the original author of the file @wangweij above to ask for guidance on this as such

I have no objection to the code change. Or maybe you can change it to the windows line extension character `^`.

I was using this command for quick recompiling while writing this code, and it's in a cmd.exe window launched with a start menu item named something like "Visual Studio Developing Environment". I wrote it inside here to remind myself if I need to rework on it.

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

PR: https://git.openjdk.org/jdk/pull/12305


From aivanov at openjdk.org  Sat Feb  4 17:25:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 4 Feb 2023 17:25:48 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
Message-ID: <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>

On Sat, 4 Feb 2023 13:36:54 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I did think about that too when I first saw it, but the command this is often run from is the Windows CMD, which does not accept `` to escape to the next line. MSYS bash does not have the required environment set up outside of configure time to run `cl` either, but I have not tested with WSL yet. I suppose one could do the complicated setup required to be able to run this from the winenv provided bash, but that seems like a lot of hassle, enough that to me someone trying to compile sspi_bridge.dll by itself wouldn't really bother with the process. On top of that cl.exe will actually interpret the backslash as the literal object file `.o` for some weird reason. I've already pinged the original author of the file @wangweij above to ask for guidance on this as such
>
> I have no objection to the code change. Or maybe you can change it to the windows line extension character `^`.
> 
> I was using this command for quick recompiling while writing this code, and it's in a cmd.exe window launched with a start menu item named something like "Visual Studio Developing Environment". I wrote it inside here to remind myself if I need to rework on it.

I used to have Visual Studio compilers available in my Cygwin environment. Now I don't, I just point the `configure` script to the batch file which configures the environment.

If this command is supposed to be run in `cmd.exe`, then `^` makes more sense: one could just copy & paste the command.

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

PR: https://git.openjdk.org/jdk/pull/12305


From duke at openjdk.org  Sat Feb  4 19:19:34 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 4 Feb 2023 19:19:34 GMT
Subject: RFR: 8301822: BasicLookAndFeel does not need to check for null after
 checking for type
Message-ID: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>

BasicLookAndFeel checks an instanceof in its `AWTEventHelper` listener class, but the result of that will always be non-null. The check should be removed.

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

Commit messages:
 - BasicLookAndFeel does not need to check for null after checking for type

Changes: https://git.openjdk.org/jdk/pull/12019/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12019&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301822
  Stats: 17 lines in 1 file changed: 2 ins; 5 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12019.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12019/head:pull/12019

PR: https://git.openjdk.org/jdk/pull/12019


From serb at openjdk.org  Sat Feb  4 19:19:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 4 Feb 2023 19:19:35 GMT
Subject: RFR: 8301822: BasicLookAndFeel does not need to check for null
 after checking for type
In-Reply-To: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
References: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
Message-ID: <63xUKK1eyG7CF2NoiFEjY2aUCPiH37E_K-TRGuKWfJM=.b86dd7ef-2c23-4a3e-80fa-775ef2219567@github.com>

On Mon, 16 Jan 2023 20:30:08 GMT, SWinxy <duke at openjdk.org> wrote:

> BasicLookAndFeel checks an instanceof in its `AWTEventHelper` listener class, but the result of that will always be non-null. The check should be removed.

Looks fine.

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

PR: https://git.openjdk.org/jdk/pull/12019


From jwaters at openjdk.org  Sat Feb  4 19:19:35 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Feb 2023 19:19:35 GMT
Subject: RFR: 8301822: BasicLookAndFeel does not need to check for null
 after checking for type
In-Reply-To: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
References: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
Message-ID: <-mOoQ9tEbWscAQY5_zYYQqE5tQdDtZytKBciyII8WmI=.447b4859-9001-47a9-aba9-2ac13bf47a47@github.com>

On Mon, 16 Jan 2023 20:30:08 GMT, SWinxy <duke at openjdk.org> wrote:

> BasicLookAndFeel checks an instanceof in its `AWTEventHelper` listener class, but the result of that will always be non-null. The check should be removed.

https://bugs.openjdk.org/browse/JDK-8301822

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

PR: https://git.openjdk.org/jdk/pull/12019


From mikael at openjdk.org  Sat Feb  4 23:11:48 2023
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Sat, 4 Feb 2023 23:11:48 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <Mn7sVCW4DX14Y-gt8vuRpxA-5oxfkdQYbjJIf6DkKLQ=.dadf5238-6d61-44e6-a85e-e4d923cb48c8@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

Out of curiosity, which version of VS 2022 is this?

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

PR: https://git.openjdk.org/jdk/pull/12427


From ysuenaga at openjdk.org  Sun Feb  5 00:42:52 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 5 Feb 2023 00:42:52 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <3QCTFOqlvgfDS3Q4ZTGt75I4ot6DQKQQ7XBEItYkKKY=.d5778a31-13dc-4499-9b9b-fc64ed071bb6@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

I uses 17.3.6 (VS Community) on Windows 11 Pro (Japanese locale (CP932))

I saw following message on the console (It is Japanese, sorry...)


d:\github-forked\jdk\src\hotspot\cpu\x86\stubGenerator_x86_64_poly.cpp(1): error C2220: ?????????????????
d:\github-forked\jdk\src\hotspot\cpu\x86\stubGenerator_x86_64_poly.cpp(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????


In case of stubGenerator_x86_64_poly.cpp , `?` in comments cannot be handled in cl.exe. I confirmed that this character cannot be handled `iconv -f CP932 -t UTF8`, so I replaced it to `x` (alphabet).

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

PR: https://git.openjdk.org/jdk/pull/12427


From serb at openjdk.org  Sun Feb  5 04:02:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 5 Feb 2023 04:02:49 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v2]
In-Reply-To: <vVc3a2bDk1asUSE-EJePj1D0jgJKCONgUAgsPo5-CHs=.384bb789-a8bc-42e6-9164-d7032beeb05a@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>
 <3U2Z--A3Y8Dn-tFKZu_SpkWPVrQtwsWKHuDxs5Qc4FE=.631a319c-ea66-4017-af5f-36f5ee2afb02@github.com>
 <vVc3a2bDk1asUSE-EJePj1D0jgJKCONgUAgsPo5-CHs=.384bb789-a8bc-42e6-9164-d7032beeb05a@github.com>
Message-ID: <s7rWp9uBwx1FhB0p-8r7rYwGrt9eZQu0G1DKb47DOFY=.917a8d63-2612-42fe-8f25-3742717b52cb@github.com>

On Fri, 3 Feb 2023 04:26:39 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 58:
>> 
>>> 56:             SwingUtilities.updateComponentTreeUI(fc);
>>> 57:             System.out.println("Nimbus font " + fc.getFont());
>>> 58:             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));
>> 
>> This will test the uninstallDefaults for the Nimbus only. I think you need to iterate all L&F twice and for the different ones check that the font will be changed(if L&Fs use different fonts).
>
> It tests for Nimbus as the fix is for that only. 
> It tests transition from Metal/Motif/Windows/WIndowsClassis->Nimbus->Metal/Motif/Windows/WindowsClassis for windows platform, say.
> We can enhance the test to test other L&F uninstallDefaults as part of test enhancement exercise in a separate JBS, which I dont think is needed for this nimbus JBS fix. 
> I hope it should not be a problem and should not be a blocker for this fix approval..

We should test that implementations of uninstallDefaults in other L&F do not have the same bug, this version always check the same uninstallDefaults in Nimbus only?

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

PR: https://git.openjdk.org/jdk/pull/12180


From serb at openjdk.org  Sun Feb  5 04:08:48 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 5 Feb 2023 04:08:48 GMT
Subject: RFR: 8301342: Prefer ArrayList to LinkedList in LayoutComparator
In-Reply-To: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
References: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
Message-ID: <FA2d2zqsgUIxzy-fGaWLgF2c_kdlICcfQsY6HYAb8hs=.d682207e-c2c1-458d-a6e5-1d9dc1863bcb@github.com>

On Sat, 28 Jan 2023 14:54:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12274


From duke at openjdk.org  Sun Feb  5 08:05:15 2023
From: duke at openjdk.org (ScientificWare)
Date: Sun, 5 Feb 2023 08:05:15 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v25]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <KdepoAlhAODl0q_vfdIqzNoPBFj0RUc9bWtSikrt9PI=.8805a898-5031-43e3-9178-8cc27b5a616f@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)

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

  Removes tag and adds missing block tag.
  
  Removes unnecessary last <p> tag and adds missing block  @return tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/7c2fc48c..5db58bda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=23-24

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

PR: https://git.openjdk.org/jdk/pull/9825


From aturbanov at openjdk.org  Sun Feb  5 08:47:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 5 Feb 2023 08:47:54 GMT
Subject: Integrated: 8301342: Prefer ArrayList to LinkedList in
 LayoutComparator
In-Reply-To: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
References: <Lb8r9AULVVdbUx9R8NUUYB9BGHYgi9uKU36pmeo42_E=.422d3284-5ab0-484d-8544-e25b8a63ae03@github.com>
Message-ID: <JMa5uxXYe-pKKN1eWn0NVF0ULzdUsM-uz6nd0H6l_XU=.360d0762-1af9-4fda-938f-64b4fbab892c@github.com>

On Sat, 28 Jan 2023 14:54:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

This pull request has now been integrated.

Changeset: d67bfe21
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d67bfe21a23fea2d9ef4eef4e811b774cca2ab94
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8301342: Prefer ArrayList to LinkedList in LayoutComparator

Reviewed-by: prr, serb

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

PR: https://git.openjdk.org/jdk/pull/12274


From duke at openjdk.org  Sun Feb  5 09:15:51 2023
From: duke at openjdk.org (ScientificWare)
Date: Sun, 5 Feb 2023 09:15:51 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v23]
In-Reply-To: <R9GPOwfz4P_7tN1eqg-1vViRTDti-A53lx_Hf9sOIjY=.4bd5da4e-997e-4986-be2d-876e6ba5246b@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <qWZ8Q93-SWoBl_D7q8674PikffSKfYq3kOW2b5zoJG8=.ee53bb48-d3e6-40af-bdfe-59b502af2621@github.com>
 <muHGFzojNURqpUi7mtVX8c48gXietTq4Jha_mEEET7M=.942543f9-d3ba-47be-b3cc-3be1326feb42@github.com>
 <R9GPOwfz4P_7tN1eqg-1vViRTDti-A53lx_Hf9sOIjY=.4bd5da4e-997e-4986-be2d-876e6ba5246b@github.com>
Message-ID: <6pdZ_3p87ELQ5egWojmtu71tO1HIvXr9MCkdv5bTnU4=.1e6c9861-cc6b-433b-9fef-c2b23f7f0e31@github.com>

On Wed, 25 Jan 2023 22:13:16 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Still waiting a review.
>
> @scientificware could you put your suggested text into the code change? I mean incorporate into the PR itself.
> 
> Is it necessary to have the _long_ sample code?
> 
>> @aivanov-jdk Can we dissociate the release of the code from the stringToColor specification update ? I'm not ready with [rgb implementation](https://bugs.openjdk.org/browse/JDK-8294090) as described in this specifications.
> 
> If the other part isn't ready yet, let's skip it for now. Once ready, you'll update the javadoc accordingly.

@aivanov-jdk I made the requestd changes.

But there some checks are now not succesful. I don't know why.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aturbanov at openjdk.org  Sun Feb  5 09:24:30 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 5 Feb 2023 09:24:30 GMT
Subject: RFR: 8301828: Avoid unnecessary array fill after creation in
 javax.swing.text
Message-ID: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>

No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

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

Commit messages:
 - [PATCH] Avoid unnecessary array fill after creation in javax.swing.text

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

PR: https://git.openjdk.org/jdk/pull/12235


From duke at openjdk.org  Sun Feb  5 09:24:30 2023
From: duke at openjdk.org (SWinxy)
Date: Sun, 5 Feb 2023 09:24:30 GMT
Subject: RFR: 8301828: Avoid unnecessary array fill after creation in
 javax.swing.text
In-Reply-To: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
References: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
Message-ID: <Mv9kPImLcjK8ZQLS-gxIdf6UfLm_tt2zqwnL1vefh1k=.78376788-45c5-45c9-a031-5bb0facfe3d5@github.com>

On Thu, 26 Jan 2023 20:58:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/12235


From serb at openjdk.org  Sun Feb  5 09:24:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 5 Feb 2023 09:24:30 GMT
Subject: RFR: 8301828: Avoid unnecessary array fill after creation in
 javax.swing.text
In-Reply-To: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
References: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
Message-ID: <05W3x879DELARVgkzOEV-YnJEmiWakULfpsM0WFo1KI=.ac241316-07ae-4c4f-899c-eeb2c587f6a7@github.com>

On Thu, 26 Jan 2023 20:58:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

Looks fine.

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

PR: https://git.openjdk.org/jdk/pull/12235


From duke at openjdk.org  Sun Feb  5 09:29:26 2023
From: duke at openjdk.org (ScientificWare)
Date: Sun, 5 Feb 2023 09:29:26 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v26]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <IOcF_B28rD_4VA2fbGB80a1-7HhXLdXamH9py_B1x5U=.9c59aa59-fc46-4047-bbe8-c8a865f3a3db@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)

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

 - Updates copyright date.
   
   Updates copyright date to 2023.
 - Updates copyright date.
   
   Updates copyright date to 2023.
 - Updates copyright date.
   
   Updates copyright date to 2023.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/5db58bda..ecba3bd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=24-25

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Sun Feb  5 09:55:27 2023
From: duke at openjdk.org (ScientificWare)
Date: Sun, 5 Feb 2023 09:55:27 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v13]
In-Reply-To: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
Message-ID: <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
> 
> This is tracked in JBS as 
> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
> 
> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
> 
> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)

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

 - Updates copyright date.
   
   Updates copyright date to 2023.
 - Updates copyright date.
   
   Updates copyright date to 2023.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10317/files
  - new: https://git.openjdk.org/jdk/pull/10317/files/433e76f7..82946cce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10317&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/10317


From jwaters at openjdk.org  Sun Feb  5 15:57:50 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 5 Feb 2023 15:57:50 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
Message-ID: <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>

On Sat, 4 Feb 2023 17:23:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I have no objection to the code change. Or maybe you can change it to the windows line extension character `^`.
>> 
>> I was using this command for quick recompiling while writing this code, and it's in a `cmd.exe` window launched with a start menu item named something like "Visual Studio Developing Environment". I wrote it inside here to remind myself if I need to rework on it.
>
> I used to have Visual Studio compilers available in my Cygwin environment. Now I don't, I just point the `configure` script to the batch file which configures the environment.
> 
> If this command is supposed to be run in `cmd.exe`, then `^` makes more sense: one could just copy & paste the command.

I've just tried copying and pasting the command with ^ instead of \ and cmd doesn't seem to be correctly reading the compile command either even with ^, is there something I'm missing here?

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

PR: https://git.openjdk.org/jdk/pull/12305


From jwaters at openjdk.org  Sun Feb  5 16:28:14 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 5 Feb 2023 16:28:14 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v3]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <PLFBOlGFegk6k9TN6leiJlUSM58YGt5HScXAjj5pVZY=.fcf3d3b1-f57f-480f-8c5f-5f330f06bdeb@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

  awt_Toolkit.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/6b17f624..99aed8a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12305


From weijun at openjdk.org  Sun Feb  5 17:30:48 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Sun, 5 Feb 2023 17:30:48 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
 <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
Message-ID: <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>

On Sun, 5 Feb 2023 15:55:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I used to have Visual Studio compilers available in my Cygwin environment. Now I don't, I just point the `configure` script to the batch file which configures the environment.
>> 
>> If this command is supposed to be run in `cmd.exe`, then `^` makes more sense: one could just copy & paste the command.
>
> I've just tried copying and pasting the command with ^ instead of \ and cmd doesn't seem to be correctly reading the compile command either even with ^, is there something I'm missing here?

I don't know. I'm quite sure I was using the full command in `cmd.exe` after calling some `vcvars64.bat`. I added the `` character because it's a little long to be recorded here. I don't really care which separator is used. You can remove the `` character. We don't need to spend too much time on this.

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

PR: https://git.openjdk.org/jdk/pull/12305


From swinxythecat at gmail.com  Sun Feb  5 22:03:35 2023
From: swinxythecat at gmail.com (SWinxy)
Date: Sun, 5 Feb 2023 17:03:35 -0500
Subject: Enhancing java2d Image classes & pipelines to support HDR (10b)
 or 16bits RGBA
In-Reply-To: <CAKjRUT4ikL859oL8MPNVpkye0YbsZU8eU2838oUq67pK-MFYrg@mail.gmail.com>
References: <CAKjRUT4ikL859oL8MPNVpkye0YbsZU8eU2838oUq67pK-MFYrg@mail.gmail.com>
Message-ID: <CAPRuVTXv4qadH5DmGe6ALrfMgEt_QDf=wZdDEUnnrsfpQNf8FQ@mail.gmail.com>

I support this! HDR support would be nice, but if there are issues with
color spaces, that to me is a higher priority.

What do you mean to fix in the macros and graphics pipelines?

On Thu, Jan 26, 2023 at 5:11 AM Laurent Bourg?s <bourges.laurent at gmail.com>
wrote:

> Hi,
>
> I would like enhancing Java Image classes (awt / java2D) to support
> natively new image types with their use cases:
> - BGRA (inverse RGBA) with both byte, integer & PREMUL variants (4x8bits),
> as supported by skia, metal, vulkan apis
> - 10 or 16 bits per RGBA component to support HDR or 64bits images like
> R10G10B10A2 or R16G16B16A16, as supported by skia, metal, vulkan apis but
> also by PNG & TIFF file formats
>
> It represents a lot of work:
> - CSR to define new BufferedImageType, Image API changes to deal with
> short / long values (rgba 48 or 64bits)
> - fix native software loops (macros)
> - fix DirectX, OpenGL, XRender, Metal pipelines for accelerated Surface
>
> Ideally such image handling requires to handle properly gamma correction &
> colorspaces (linear RGBA or perceptual sRGB, P3...) but it is maybe another
> topic !
>
> Comments are welcome & potential use cases too,
>
> Thanks,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230205/b7ac7430/attachment.htm>

From dholmes at openjdk.org  Mon Feb  6 01:08:49 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 6 Feb 2023 01:08:49 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <w77y3xj7j9OXjIFUH86lSFz0Je8R79FMoY6wAvE9PRw=.b2c037c8-f6c3-472b-977c-ad55ceeb5939@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

Sorry Yasumasa, but I'd much prefer to see this split into three sub-tasks (or issues) just so we can keep the issues more clearly separated.

IIUC for stubGenerator_x86_64_poly.cpp we have a multiplication symbol instead of an ascii 'x' (likely pasted from a word processing document).

For elfFile.hpp there are smart-quotes instead of ascii "

Thanks.

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

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12427


From jwaters at openjdk.org  Mon Feb  6 03:37:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 6 Feb 2023 03:37:03 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v4]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <mzI7SEq3zv3egItZTlRd66dZ0tyhRKB0_1ngBxgiVWg=.4c93a2ea-7ba3-469a-8df9-f46603e58d23@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

  sspi.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/99aed8a0..24becec8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=02-03

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

PR: https://git.openjdk.org/jdk/pull/12305


From jwaters at openjdk.org  Mon Feb  6 03:37:04 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 6 Feb 2023 03:37:04 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
 <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
 <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>
Message-ID: <SI9ksB_ugdnmIP9OF3CPWqM_HDjZcHyLlwmsg8L6oiY=.b3114edb-bbfe-48f0-a086-39f79f713f6b@github.com>

On Sun, 5 Feb 2023 17:26:29 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> I've just tried copying and pasting the command with ^ instead of \ and cmd doesn't seem to be correctly reading the compile command either even with ^, is there something I'm missing here?
>
> I don't know. I'm quite sure I was using the full command in `cmd.exe` after calling some `vcvars64.bat`. I added the `` character because it's a little long to be recorded here. I don't really care which separator is used. You can remove the `` character. We don't need to spend too much time on this.

Honestly, with all of this confusion around the command line, I think I'd rather just avoid the issue entirely by turning this into a multiline comment so the backslash doesn't cause compiler warnings

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

PR: https://git.openjdk.org/jdk/pull/12305


From jdv at openjdk.org  Mon Feb  6 04:45:50 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 6 Feb 2023 04:45:50 GMT
Subject: RFR: 7169951: SwingSet2 throws NullPointerException with Nimbus
 L&F
In-Reply-To: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
References: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
Message-ID: <gYqdtf0D9W64r91_VowR3dGfBhjJGIeuSog6JAQKyk0=.00d99ded-334b-472a-ae39-1282318603d9@github.com>

On Fri, 13 Jan 2023 04:25:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is observed that if SwingSet2 is run in Nimbus L&F and
> we drag the icon tool bar (which is floatable) out of the GUI Window
> and  Once the tool bar is detached, click on "Look & Feel" menu option to change to any L&F (say Java L&F)
> it causes NPE due to font being null when getFontMetrics() is called
> 
> In other L&F, it uses the tabPane's [font ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTabbedPaneUI.java#L2177) whereas in Nimbus font is obtained from getStyle().getFont() which returns null when toolbar is detached from the main window.
> The proposed fix is to get tabPane's font if the font passed is null alike other L&Fs. 
> 
> No regression test is made as it can be verified with SwingSet2..

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11984


From jdv at openjdk.org  Mon Feb  6 04:52:49 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 6 Feb 2023 04:52:49 GMT
Subject: RFR: 8297454: javax/swing/JComponent/7154030/bug7154030.java
 failed with "Exception: Failed to show opaque button"
In-Reply-To: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
References: <nIuP21ewUd0nALclypyH1ULkFk_cAq5q34LIxmCloUs=.a7326479-4586-4a2f-bb38-15d572a4512d@github.com>
Message-ID: <LsrQy1IzNdgcrRGE-PnxGs-g_lUiXSMfMGk9HOrLirE=.2c1c63cf-e310-4e0a-8e6f-0413833fc9a6@github.com>

On Wed, 25 Jan 2023 06:41:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test intermittently failed in CI macos system owing to robot screencapture failing to compare the images.
> Seems like from artifacts, that composite image created by robot contains mouse cursor, which when compared are not giving exact pixel color. This has occurred in the past also for some tests for which we have made the mouseMove to move mouse cursor outside the area being captured for pixel comparison.
> Similar fix is done whereby mouse is moved to outside the captured area. Several iterations in CI are ok.

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12179


From abhiscxk at openjdk.org  Mon Feb  6 05:03:51 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 6 Feb 2023 05:03:51 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v3]
In-Reply-To: <sZOcdXuQ6PM5VhZK__K5_7DPOMNfZ-jx6m891_ldtCo=.8e9dee5d-b0e3-4ec2-9031-8df7cf6f728b@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <sZOcdXuQ6PM5VhZK__K5_7DPOMNfZ-jx6m891_ldtCo=.8e9dee5d-b0e3-4ec2-9031-8df7cf6f728b@github.com>
Message-ID: <V_UZRdqtejbsc6NXK-PLdvc0-sjca5bnK_hXeE53dxk=.8a76e94b-85c8-4f6e-898a-7d3eb1207ae1@github.com>

On Fri, 3 Feb 2023 19:56:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify Nimbus LAF check

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTest.java line 53:

> 51: 
> 52:     private static JFrame frame;
> 53:     private static boolean hasNimbus;

`hasNimbus `variable is unused now, can be removed.

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTest.java line 118:

> 116:             UIManager.setLookAndFeel("javax.swing.plaf.nimbus.NimbusLookAndFeel");
> 117:         }
> 118:         catch (Exception e) {

Just a suggestion, try-catch block can be like

try {
   ...
} catch {
   ...
}

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

PR: https://git.openjdk.org/jdk/pull/12390


From jdv at openjdk.org  Mon Feb  6 05:59:50 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 6 Feb 2023 05:59:50 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
Message-ID: <EpedgB4SzjULdNlGBffop07yeZMgqdmvx2Yf1NFtQmo=.fb921778-f823-4a62-8bfc-1118ead2683a@github.com>

On Thu, 2 Feb 2023 17:39:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
>> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
>> 
>> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
>> 
>> No regression test is added as it can be verified by SwingSet2 Tabledemo..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test fix

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 234:

> 232:         }
> 233:         SynthContext context = getContext(table, ENABLED);
> 234:         if (showHorizLines) {

I think we should make this condition tighter to avoid unnecessary repaints like in GTK LAF.
Like only when current property is false and we expect it to be true and then only call setShowHorizontal/VerticalLines()

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

PR: https://git.openjdk.org/jdk/pull/12385


From psadhukhan at openjdk.org  Mon Feb  6 08:46:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 08:46:24 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v3]
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <Xxe4c_uAxpqTWO1033ocJUfEIS6XlD6Zk6VfPAwb8oE=.e81a4ef3-1f2e-4fc5-93c9-9db8e465ba0e@github.com>

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

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

  Test other L&F uninstallDefault

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12180/files
  - new: https://git.openjdk.org/jdk/pull/12180/files/a704310e..3f6f018e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=01-02

  Stats: 23 lines in 1 file changed: 11 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12180.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12180/head:pull/12180

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Mon Feb  6 08:46:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 08:46:24 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v2]
In-Reply-To: <s7rWp9uBwx1FhB0p-8r7rYwGrt9eZQu0G1DKb47DOFY=.917a8d63-2612-42fe-8f25-3742717b52cb@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <3BtuavqYdt0jgniOlHFPZ8fm6gJvMPvqfkp7pMu67-s=.dbff2a1e-3f5b-46a4-a24d-2cceeb22284c@github.com>
 <3U2Z--A3Y8Dn-tFKZu_SpkWPVrQtwsWKHuDxs5Qc4FE=.631a319c-ea66-4017-af5f-36f5ee2afb02@github.com>
 <vVc3a2bDk1asUSE-EJePj1D0jgJKCONgUAgsPo5-CHs=.384bb789-a8bc-42e6-9164-d7032beeb05a@github.com>
 <s7rWp9uBwx1FhB0p-8r7rYwGrt9eZQu0G1DKb47DOFY=.917a8d63-2612-42fe-8f25-3742717b52cb@github.com>
Message-ID: <v6Rs1C3Oead_U1sbmLFjSu2_3xm6Sd2LMErJNkIOMis=.1b8b2946-8ee3-49a4-a0ec-c018ea3d77c7@github.com>

On Sun, 5 Feb 2023 03:59:57 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It tests for Nimbus as the fix is for that only. 
>> It tests transition from Metal/Motif/Windows/WIndowsClassis->Nimbus->Metal/Motif/Windows/WindowsClassis for windows platform, say.
>> We can enhance the test to test other L&F uninstallDefaults as part of test enhancement exercise in a separate JBS, which I dont think is needed for this nimbus JBS fix. 
>> I hope it should not be a problem and should not be a blocker for this fix approval..
>
> We should test that implementations of uninstallDefaults in other L&F do not have the same bug, this version always check the same uninstallDefaults in Nimbus only?

Yes, but I think that test enhancement should have been a suggestion and not a blocker for this fix.
Anyways, I have updated..

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

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Mon Feb  6 08:50:53 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 08:50:53 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <EpedgB4SzjULdNlGBffop07yeZMgqdmvx2Yf1NFtQmo=.fb921778-f823-4a62-8bfc-1118ead2683a@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
 <EpedgB4SzjULdNlGBffop07yeZMgqdmvx2Yf1NFtQmo=.fb921778-f823-4a62-8bfc-1118ead2683a@github.com>
Message-ID: <qsvHct5j13fVwbNLHFI421MEOYXEW9XSRze6Y743Wy0=.d98ea37c-c343-4389-8ff1-1ac1bffe84ec@github.com>

On Mon, 6 Feb 2023 05:56:49 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test fix
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 234:
> 
>> 232:         }
>> 233:         SynthContext context = getContext(table, ENABLED);
>> 234:         if (showHorizLines) {
> 
> I think we should make this condition tighter to avoid unnecessary repaints like in GTK LAF.
> Like only when current property is false and we expect it to be true and then only call setShowHorizontal/VerticalLines()

I am not sure what you meant..
uninstallDefaults will be called only once during L&F transition from Nimbus to other L&F and
 it will set horizontal and vertical lines only if it was set in other L&F before Nimbus L&F takes effect..
If other L&F did not have those set, it will not call setShowHorizontal/VerticalLines()

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

PR: https://git.openjdk.org/jdk/pull/12385


From psadhukhan at openjdk.org  Mon Feb  6 08:54:00 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 08:54:00 GMT
Subject: Integrated: 4934362: see also refers to self
In-Reply-To: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
References: <o4CshA2ykwcnWovFecnDF6x9TsxedTOVz1CG3wCCsnA=.af2f2bb7-4877-47d9-a4cc-067bf3cbfbe0@github.com>
Message-ID: <y-sB-jEqGt6lG-eT_lxmMHifSFniLoI779Xs3QHq8sg=.4a3717b6-8a8c-4827-80b8-7071aa2703e3@github.com>

On Tue, 3 Jan 2023 06:00:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Some methods and constants has a hyperreference to self in javadoc which is rectified to reference proper methods

This pull request has now been integrated.

Changeset: ab528ce3
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ab528ce3cd4bb75a00f5eaadae1f5e45d26712b5
Stats:     27 lines in 10 files changed: 4 ins; 4 del; 19 mod

4934362: see also refers to self

Reviewed-by: prr, serb, aivanov

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

PR: https://git.openjdk.org/jdk/pull/11820


From jdv at openjdk.org  Mon Feb  6 09:23:53 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 6 Feb 2023 09:23:53 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <qsvHct5j13fVwbNLHFI421MEOYXEW9XSRze6Y743Wy0=.d98ea37c-c343-4389-8ff1-1ac1bffe84ec@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
 <EpedgB4SzjULdNlGBffop07yeZMgqdmvx2Yf1NFtQmo=.fb921778-f823-4a62-8bfc-1118ead2683a@github.com>
 <qsvHct5j13fVwbNLHFI421MEOYXEW9XSRze6Y743Wy0=.d98ea37c-c343-4389-8ff1-1ac1bffe84ec@github.com>
Message-ID: <bPl-vmc9JgngMnTIwY1tRmDb04N6kx-9SL0KCxqAh0I=.0963bc17-1b6b-4620-bfda-e6eb74777aa0@github.com>

On Mon, 6 Feb 2023 08:48:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 234:
>> 
>>> 232:         }
>>> 233:         SynthContext context = getContext(table, ENABLED);
>>> 234:         if (showHorizLines) {
>> 
>> I think we should make this condition tighter to avoid unnecessary repaints like in GTK LAF.
>> Like only when current property is false and we expect it to be true and then only call setShowHorizontal/VerticalLines()
>
> I am not sure what you meant..
> uninstallDefaults will be called only once during L&F transition from Nimbus to other L&F and
>  it will set horizontal and vertical lines only if it was set in other L&F before Nimbus L&F takes effect..
> If other L&F did not have those set, it will not call setShowHorizontal/VerticalLines()

Will uninstallDefaults() be called for GTK -> other LAF transition?
I was thinking SynthTableUI is common for all SynthLAF's and if we are transitioning from GTK -> Other LAF's there is no need to call setShowHorizontal/VerticalLines(). Because as mentioned in description only Nimbus LAF will have "showGrid" as false and for GTK we will not be calling `table.setShowGrid(false);`

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

PR: https://git.openjdk.org/jdk/pull/12385


From psadhukhan at openjdk.org  Mon Feb  6 09:24:23 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 09:24:23 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v5]
In-Reply-To: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
Message-ID: <6nalpkM3XvpxqLFZ2A_fCLy4EdzwHwYSXMedLUWCOoU=.d403d0c1-6ce5-4776-b9a0-012cff735f8f@github.com>

> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
> says:
> "...MetalLookAndFeel registers an entry for each of the classes
> in the package javax.swing.plaf.metal that are named MetalXXXUI.
> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
> that do not have a class in metal, the corresponding class in
> javax.swing.plaf.basic is used. For example, metal does not
> have a class named "MetalColorChooserUI", as such,
> javax.swing.plaf.basic.BasicColorChooserUI is used".
> 
> There is class MetalMenuBarUI, but the method populates given defaults table with the value
> "javax.swing.plaf.basic.BasicMenuBarUI".
> 
> Added entry for MetalMenuBarUI..
> CI tests including JCK tests are ok.

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

  Add MetalMenuBarUI in MetalL&F

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11646/files
  - new: https://git.openjdk.org/jdk/pull/11646/files/4a38b8c1..c45f53e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11646&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11646&range=03-04

  Stats: 11 lines in 2 files changed: 1 ins; 8 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/11646.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11646/head:pull/11646

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Mon Feb  6 09:26:52 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 09:26:52 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v4]
In-Reply-To: <1d2W0Lz8GsavwyVRvEFk4yDlhtvUrN2PCRpmu4CxWtM=.cdc2e940-3ea5-45cb-81a3-bde501228461@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <KyXt0enZuPEsiGn7Yc2jvDEtqssvtR9qgdt4ykCdPKI=.821dea40-4aa9-4349-9e0e-3c3a0a070301@github.com>
 <1d2W0Lz8GsavwyVRvEFk4yDlhtvUrN2PCRpmu4CxWtM=.cdc2e940-3ea5-45cb-81a3-bde501228461@github.com>
Message-ID: <SPNpTdH3pm1h7dl5hninndoQ5msgk5asSzBGUA8eMs4=.e3222642-1d40-4570-8303-2e3e6e8b5509@github.com>

On Fri, 3 Feb 2023 18:09:06 GMT, Phil Race <prr at openjdk.org> wrote:

> These words - "This class is only appropriate for Ocean. The spec needs to be updated to mention this."
> 
> WHY can no other Theme use it ? Is there a reason ? I think the comment does not have enough backing explanation to be simply followed blindly.

I think you are right.
As per MetalMenuBarUI spec also, it is mentioned "Metal implementation of <code>MenuBarUI</code>. This class is responsible for providing the metal look and feel for <code>JMenuBar</code>s."

ie it is mentioned for Metal L&F and not for a particular theme

so I have reinstated my 1st iteration of the PR..
Please review...

All clientlibs tests are ok, link in JBS

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

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Mon Feb  6 10:14:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 10:14:12 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v5]
In-Reply-To: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
Message-ID: <9isfpPmDbm6x0J3OiEypPfSYS7UKhmHY1IVig8FWdq8=.3ca9af78-6ee2-4374-a593-4cebc2a2d8c3@github.com>

> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
> 
> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
> 
> No regression test is added as it can be verified by SwingSet2 Tabledemo..

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

  Ignore set horiz/vert lines if showGrid is true by default

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12385/files
  - new: https://git.openjdk.org/jdk/pull/12385/files/c1d64881..1a456cc7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=03-04

  Stats: 10 lines in 1 file changed: 3 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12385.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12385/head:pull/12385

PR: https://git.openjdk.org/jdk/pull/12385


From psadhukhan at openjdk.org  Mon Feb  6 10:14:13 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Feb 2023 10:14:13 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v4]
In-Reply-To: <bPl-vmc9JgngMnTIwY1tRmDb04N6kx-9SL0KCxqAh0I=.0963bc17-1b6b-4620-bfda-e6eb74777aa0@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <0Gdkp3X0sMMZ6_e_Kkrzv6ZpTJe5DD7o_0pWb-h15IU=.72a40c15-a306-4657-8bb6-f32e7aae4681@github.com>
 <EpedgB4SzjULdNlGBffop07yeZMgqdmvx2Yf1NFtQmo=.fb921778-f823-4a62-8bfc-1118ead2683a@github.com>
 <qsvHct5j13fVwbNLHFI421MEOYXEW9XSRze6Y743Wy0=.d98ea37c-c343-4389-8ff1-1ac1bffe84ec@github.com>
 <bPl-vmc9JgngMnTIwY1tRmDb04N6kx-9SL0KCxqAh0I=.0963bc17-1b6b-4620-bfda-e6eb74777aa0@github.com>
Message-ID: <PbPuAbSktm4hVu5TjPnTdB0HJXcDJ3WjJOO-2XcnTug=.3f006bbd-8075-472b-8f3e-469374a08801@github.com>

On Mon, 6 Feb 2023 09:21:04 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> I am not sure what you meant..
>> uninstallDefaults will be called only once during L&F transition from Nimbus to other L&F and
>>  it will set horizontal and vertical lines only if it was set in other L&F before Nimbus L&F takes effect..
>> If other L&F did not have those set, it will not call setShowHorizontal/VerticalLines()
>
> Will uninstallDefaults() be called for GTK -> other LAF transition?
> I was thinking SynthTableUI is common for all SynthLAF's and if we are transitioning from GTK -> Other LAF's there is no need to call setShowHorizontal/VerticalLines(). Because as mentioned in description only Nimbus LAF will have "showGrid" as false and for GTK we will not be calling `table.setShowGrid(false);`

Yes, for GTK showGrid is true so we can add that condition..
Fix updated...

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

PR: https://git.openjdk.org/jdk/pull/12385


From jdv at openjdk.org  Mon Feb  6 11:15:52 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 6 Feb 2023 11:15:52 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v5]
In-Reply-To: <9isfpPmDbm6x0J3OiEypPfSYS7UKhmHY1IVig8FWdq8=.3ca9af78-6ee2-4374-a593-4cebc2a2d8c3@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <9isfpPmDbm6x0J3OiEypPfSYS7UKhmHY1IVig8FWdq8=.3ca9af78-6ee2-4374-a593-4cebc2a2d8c3@github.com>
Message-ID: <G77keTev8if_I6mCbW3rGdZlYoEnWvZ_EGkkKqiPDBc=.b11a572b-7afd-4eb0-8b02-2b32ebffd1f4@github.com>

On Mon, 6 Feb 2023 10:14:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
>> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
>> 
>> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
>> 
>> No regression test is added as it can be verified by SwingSet2 Tabledemo..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore set horiz/vert lines if showGrid is true by default

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12385


From ysuenaga at openjdk.org  Mon Feb  6 12:40:04 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:40:04 GMT
Subject: RFR: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <w77y3xj7j9OXjIFUH86lSFz0Je8R79FMoY6wAvE9PRw=.b2c037c8-f6c3-472b-977c-ad55ceeb5939@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
 <w77y3xj7j9OXjIFUH86lSFz0Je8R79FMoY6wAvE9PRw=.b2c037c8-f6c3-472b-977c-ad55ceeb5939@github.com>
Message-ID: <h7rEtEtX-O-KtH6CcMU5-Pp7zOjYlT_tB41ARNNEFKc=.93556cb3-64fd-4565-9df0-a75ac05fea49@github.com>

On Mon, 6 Feb 2023 01:06:32 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
>> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
>> 
>> * HotSpot
>>     * stubGenerator_x86_64_poly.cpp
>>     * elfFile.hpp
>> * libfontmanager
>>     * hb.hh
>> * libfreetype
>>     * afblue.c
>> 
>> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.
>
> Sorry Yasumasa, but I'd much prefer to see this split into three sub-tasks (or issues) just so we can keep the issues more clearly separated.
> 
> IIUC for stubGenerator_x86_64_poly.cpp we have a multiplication symbol instead of an ascii 'x' (likely pasted from a word processing document).
> 
> For elfFile.hpp there are smart-quotes instead of ascii "
> 
> Thanks.

@dholmes-ora I splitted this in three sub tasks as #12435, #12436, #12437.  
I hope they are reviewed and merged.

So I close this PR (but I do not close this issue on JBS until all subtasks are resolved).

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

PR: https://git.openjdk.org/jdk/pull/12427


From ysuenaga at openjdk.org  Mon Feb  6 12:40:05 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:40:05 GMT
Subject: Withdrawn: 8301820: C4819 warnings were reported on Windows
In-Reply-To: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
References: <SdpGH9dU5Mw4aNmuH7fmgnZc6IG8_Ass9pu9hlZmy_Y=.fd342dc6-51da-4697-ae40-5d64c361de33@github.com>
Message-ID: <UmijvS_DQJhUKJQKPpMwxP0PCTJ38dknwpTaU1buuNY=.a3ec3ec9-dbf6-47e8-ac44-bb91cbfb19e2@github.com>

On Sat, 4 Feb 2023 09:42:57 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> C4819 warnings were reported when I tried to build JDK on Windows with VS2022.
> This PR contains changes both HotSpot and client libraries. Let me know if they should be separated.
> 
> * HotSpot
>     * stubGenerator_x86_64_poly.cpp
>     * elfFile.hpp
> * libfontmanager
>     * hb.hh
> * libfreetype
>     * afblue.c
> 
> I added C4819 to `DISABLED_WARNINGS_microsoft` for libfontmanager and for libfreetype because they are 3rd-party libraries.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12427


From ysuenaga at openjdk.org  Mon Feb  6 12:42:43 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:42:43 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on Windows
Message-ID: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>

This is subtask of https://github.com/openjdk/jdk/pull/12427 .

I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)


d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????


I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

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

Commit messages:
 - 8301854: C4819 warnings were reported in libfreetype on Windows

Changes: https://git.openjdk.org/jdk/pull/12436/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12436&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301854
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12436.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12436/head:pull/12436

PR: https://git.openjdk.org/jdk/pull/12436


From ysuenaga at openjdk.org  Mon Feb  6 12:44:24 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 6 Feb 2023 12:44:24 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
Message-ID: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>

This is subtask of https://github.com/openjdk/jdk/pull/12427 .

I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)


d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????


I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

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

Commit messages:
 - 8301855: C4819 warnings were reported in harfbuzz on Windows

Changes: https://git.openjdk.org/jdk/pull/12437/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12437&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301855
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12437.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12437/head:pull/12437

PR: https://git.openjdk.org/jdk/pull/12437


From ihse at openjdk.org  Mon Feb  6 13:51:49 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 6 Feb 2023 13:51:49 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <4P8uUwzk0rgPNXiw-3LEkWcbvzepHojoVDJDYz0ilsU=.55f4d537-6a77-489d-a40c-e26a0aaa9416@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

So to add some context to this and the related PRs.  **C4819** has this official description:

`The file contains a character that cannot be represented in the current code page (number). Save the file in Unicode format to prevent data loss.`

So, this is not so much a compilation error per se, but a problem with the encoding of our source code files.

Some time ago, there were a discussion that we should make sure our code base where in utf-8, instead of the current unspecified state of "mostly ascii, but some additional characters but we won't tell you which encoding, hopefully it's latin-1". 

I'm thinking the correct choice is maybe not to silence the warning, but to actually put down our collective feet, say "enough is enough of this nonsense!", declare the source to be utf-8, turn on all flags needed to get our tools to recognize this fact, and then go on with our lives.

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

PR: https://git.openjdk.org/jdk/pull/12436


From philip.race at oracle.com  Mon Feb  6 16:43:19 2023
From: philip.race at oracle.com (Philip Race)
Date: Mon, 6 Feb 2023 08:43:19 -0800
Subject: Enhancing java2d Image classes & pipelines to support HDR (10b)
 or 16bits RGBA
In-Reply-To: <CAKjRUT4ikL859oL8MPNVpkye0YbsZU8eU2838oUq67pK-MFYrg@mail.gmail.com>
References: <CAKjRUT4ikL859oL8MPNVpkye0YbsZU8eU2838oUq67pK-MFYrg@mail.gmail.com>
Message-ID: <8e223b31-2035-199b-9d43-4312ff95434f@oracle.com>

Whilst I've thought about this a couple of times, I only thought about 
it very briefly
because it spans so much .. and is a lot of work as you lay out, and we 
have other
projects like Wakefield for example. And as for D3D, I am not sure how 
we can even
address HDR without upgrading our D3D pipeline to DX12 .. which in itself is
something that is a higher priority - DX 9 is ancient and doesn't 
support it.
And the number of customer requests to date is zero.

BRGA seems like something that we'd currently handle as a custom image 
format.
Is there a use case for this ?

We'd also have to consider that we ought to be looking at it for FX too ..

-phil.

On 1/26/23 2:10 AM, Laurent Bourg?s wrote:
> Hi,
>
> I would like enhancing Java Image classes (awt / java2D) to support 
> natively new image types with their use cases:
> - BGRA (inverse RGBA) with both byte, integer & PREMUL variants 
> (4x8bits), as supported by skia, metal, vulkan apis
> - 10 or 16 bits per RGBA component to support HDR or 64bits images 
> like R10G10B10A2 or R16G16B16A16, as supported by skia, metal, vulkan 
> apis but also by PNG & TIFF file formats
>
> It represents a lot of work:
> - CSR to define new BufferedImageType, Image API changes to deal with 
> short / long values (rgba 48 or 64bits)
> - fix native software loops (macros)
> - fix DirectX, OpenGL, XRender, Metal pipelines for accelerated Surface
>
> Ideally such image handling requires to handle properly gamma 
> correction & colorspaces (linear RGBA or perceptual sRGB, P3...) but 
> it is maybe another topic !
>
> Comments are welcome & potential use cases too,
>
> Thanks,
> Laurent



From prr at openjdk.org  Mon Feb  6 17:14:49 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Feb 2023 17:14:49 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <KuxhuPLyqOFum-vJF-ffkOhYK-ccvd0m2Z_xncwxtAI=.ae0c5280-f4c2-45ce-b74d-367b2e0d8855@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I notice you didn't bother telling folks what this warning is 
It is
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-warnings/compiler-warning-level-1-c4819?view=msvc-170
"The file contains a character that cannot be represented in the current code page (number)."

JDK does not support being built in arbitrary locales. 
And the warning comes from hb.hh at some line you don't reveal so I can't tell if its in a comment or something more critical, and then since its in a central header file I can't tell if its the only such warning or not.

This fix is rejected. Build in an English locale.

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

PR: https://git.openjdk.org/jdk/pull/12437


From prr at openjdk.org  Mon Feb  6 17:17:48 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Feb 2023 17:17:48 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <V34xPoVNUSEJTPjqyo3b-E37g8zkhJQyEnhQjaHqjaQ=.33558041-c68f-49a0-9423-9d057ef21047@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

Fix rejected for the same reasons as described in https://github.com/openjdk/jdk/pull/12437

" declare the source to be utf-8, "

you can't do that if you don't own the code, can you ?
Regardless this fix isn't right.

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

PR: https://git.openjdk.org/jdk/pull/12436


From prr at openjdk.org  Mon Feb  6 17:47:51 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Feb 2023 17:47:51 GMT
Subject: RFR: 8301828: Avoid unnecessary array fill after creation in
 javax.swing.text
In-Reply-To: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
References: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
Message-ID: <x1-FuCMHDQ9-JKQgtCY3tmQcY4Rz-kooJbho5dnFPhY=.0c65b8a8-7bec-4441-8e24-a2686e6fe0e8@github.com>

On Thu, 26 Jan 2023 20:58:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12235


From dnguyen at openjdk.org  Mon Feb  6 19:04:07 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 6 Feb 2023 19:04:07 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
Message-ID: <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

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

  Remove unused var. Fix try catch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12390/files
  - new: https://git.openjdk.org/jdk/pull/12390/files/fa70b83f..99286089

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Mon Feb  6 19:04:11 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 6 Feb 2023 19:04:11 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v3]
In-Reply-To: <V_UZRdqtejbsc6NXK-PLdvc0-sjca5bnK_hXeE53dxk=.8a76e94b-85c8-4f6e-898a-7d3eb1207ae1@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <sZOcdXuQ6PM5VhZK__K5_7DPOMNfZ-jx6m891_ldtCo=.8e9dee5d-b0e3-4ec2-9031-8df7cf6f728b@github.com>
 <V_UZRdqtejbsc6NXK-PLdvc0-sjca5bnK_hXeE53dxk=.8a76e94b-85c8-4f6e-898a-7d3eb1207ae1@github.com>
Message-ID: <CLX-k0Y4zrRrT1m9qIQOISyW1OsmN0Ol4RL_tBiKpSQ=.50c20eb5-91d4-4730-be99-585bb6d7265f@github.com>

On Mon, 6 Feb 2023 04:56:57 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplify Nimbus LAF check
>
> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTest.java line 53:
> 
>> 51: 
>> 52:     private static JFrame frame;
>> 53:     private static boolean hasNimbus;
> 
> `hasNimbus `variable is unused now, can be removed.

Thanks, updated

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

PR: https://git.openjdk.org/jdk/pull/12390


From honkar at openjdk.org  Mon Feb  6 19:29:45 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 6 Feb 2023 19:29:45 GMT
Subject: RFR: JDK-8289077: Add manual tests to open
Message-ID: <kv8B_v9d7UTlJ5aXORS5wKXoY_8zQhJtksWF8Z6UyJE=.47797585-a8ed-49e3-b6e1-76ecf88b5f91@github.com>

Following manual tests added -

1. test/jdk/java/awt/Frame/ALTTABIconBeingErased/ALTTABIconBeingErased.java
2. test/jdk/java/awt/Icon/IconChangingTest/IconChangingTest.java
3. test/jdk/java/awt/Icon/IconShowingTest/IconShowingTest.java
4. test/jdk/java/awt/Icon/IconTransparencyTest/IconTransparencyTest.java
5. test/jdk/java/awt/Icon/SetLargeIconTest/SetLargeIconTest.java

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

Commit messages:
 - added manual tests

Changes: https://git.openjdk.org/jdk/pull/12447/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12447&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289077
  Stats: 940 lines in 7 files changed: 940 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12447.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12447/head:pull/12447

PR: https://git.openjdk.org/jdk/pull/12447


From aivanov at openjdk.org  Mon Feb  6 19:59:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Feb 2023 19:59:53 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v4]
In-Reply-To: <mzI7SEq3zv3egItZTlRd66dZ0tyhRKB0_1ngBxgiVWg=.4c93a2ea-7ba3-469a-8df9-f46603e58d23@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <mzI7SEq3zv3egItZTlRd66dZ0tyhRKB0_1ngBxgiVWg=.4c93a2ea-7ba3-469a-8df9-f46603e58d23@github.com>
Message-ID: <wSXV07-b_hqLtZVIfmIVUHFr9qFEneYwfL9ik7L-26Q=.0d3fc71a-b8c8-411a-8b98-e0bd6de199fb@github.com>

On Mon, 6 Feb 2023 03:37:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   sspi.cpp

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12305


From azvegint at openjdk.org  Mon Feb  6 21:02:53 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 6 Feb 2023 21:02:53 GMT
Subject: RFR: JDK-8289077: Add manual tests to open
In-Reply-To: <kv8B_v9d7UTlJ5aXORS5wKXoY_8zQhJtksWF8Z6UyJE=.47797585-a8ed-49e3-b6e1-76ecf88b5f91@github.com>
References: <kv8B_v9d7UTlJ5aXORS5wKXoY_8zQhJtksWF8Z6UyJE=.47797585-a8ed-49e3-b6e1-76ecf88b5f91@github.com>
Message-ID: <eR-ZqG0AbK1h9KDxMVLxGkcUQD2yPV4miFfkLjOrs6g=.46b607e5-c419-463e-94e3-df3e61184eb4@github.com>

On Mon, 6 Feb 2023 19:22:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Following manual tests added -
> 
> 1. test/jdk/java/awt/Frame/ALTTABIconBeingErased/ALTTABIconBeingErased.java
> 2. test/jdk/java/awt/Icon/IconChangingTest/IconChangingTest.java
> 3. test/jdk/java/awt/Icon/IconShowingTest/IconShowingTest.java
> 4. test/jdk/java/awt/Icon/IconTransparencyTest/IconTransparencyTest.java
> 5. test/jdk/java/awt/Icon/SetLargeIconTest/SetLargeIconTest.java

Marked as reviewed by azvegint (Reviewer).

test/jdk/java/awt/Icon/IconChangingTest/IconChangingTest.java line 50:

> 48:  * @build PassFailJFrame jdk.test.lib.Platform
> 49:  * @run main/manual IconChangingTest
> 50:  */

Neat: looks like a missing empty line in every test.

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

PR: https://git.openjdk.org/jdk/pull/12447


From honkar at openjdk.org  Mon Feb  6 21:40:24 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 6 Feb 2023 21:40:24 GMT
Subject: RFR: JDK-8289077: Add manual tests to open [v2]
In-Reply-To: <kv8B_v9d7UTlJ5aXORS5wKXoY_8zQhJtksWF8Z6UyJE=.47797585-a8ed-49e3-b6e1-76ecf88b5f91@github.com>
References: <kv8B_v9d7UTlJ5aXORS5wKXoY_8zQhJtksWF8Z6UyJE=.47797585-a8ed-49e3-b6e1-76ecf88b5f91@github.com>
Message-ID: <dB8Qgdq9RNmZpYORQq_UywWckAykiKu5vSKORenWQno=.c72e4923-5168-4a21-8404-2200aa6e1a48@github.com>

> Following manual tests added -
> 
> 1. test/jdk/java/awt/Frame/ALTTABIconBeingErased/ALTTABIconBeingErased.java
> 2. test/jdk/java/awt/Icon/IconChangingTest/IconChangingTest.java
> 3. test/jdk/java/awt/Icon/IconShowingTest/IconShowingTest.java
> 4. test/jdk/java/awt/Icon/IconTransparencyTest/IconTransparencyTest.java
> 5. test/jdk/java/awt/Icon/SetLargeIconTest/SetLargeIconTest.java

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

  added newline

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12447/files
  - new: https://git.openjdk.org/jdk/pull/12447/files/eacf4f29..a2363ce0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12447&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12447&range=00-01

  Stats: 6 lines in 5 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12447.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12447/head:pull/12447

PR: https://git.openjdk.org/jdk/pull/12447


From serb at openjdk.org  Mon Feb  6 22:07:01 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 6 Feb 2023 22:07:01 GMT
Subject: RFR: 8272288: Funky multiresolution image breaks graphics context
In-Reply-To: <W_nWnq9ale7jiakx-FbMzSwAcjTAW1Ymgw9ITT-nnRc=.1071a41b-39dd-40d2-b4f1-7da5a84f7a14@github.com>
References: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
 <W_nWnq9ale7jiakx-FbMzSwAcjTAW1Ymgw9ITT-nnRc=.1071a41b-39dd-40d2-b4f1-7da5a84f7a14@github.com>
Message-ID: <s2GDNJT2Zv0JimXmFG-EtF3alWT-K16tyVwHIGjuSbI=.21e9832b-b662-41c2-acbd-34480aa4f03d@github.com>

On Thu, 19 Jan 2023 08:23:15 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> This is the next iteration of fixing the issue of rendering "broken" image. The fix for [JDK-7183828](https://bugs.openjdk.org/browse/JDK-7183828) changed the possible IllegalArgumentException during rendering to the InvalidPipeException in assumtion that the new exception will be catched by the java2d machinery and the current-accelerated pipeline will be invalidated and software-pipeline will take care about that image.
>> 
>> But that change uncover another bug, the accelerated-pipeline invalidation by the InvalidPipeException works in D3D pipeline only, other pipelines start to use software based surfaces, but do not report about that the client code, as a result the next code does not work as expected, since contentsLost alwys return false:
>> 
>>         do {
>>             vi.validate(gc);
>>             Graphics2D g = vi.createGraphics();
>>             g.fillRect(0, 0, vi.getWidth(), vi.getHeight());
>>             g.dispose();
>>         } while (vi.contentsLost());
>> 
>> After this change the correct value will be reported by the contentsLost(), so the RepaintManager will be able to catch that.
>> But this fix uncovered another bug. That fallback code path in the RepaintManager was not tested on HiDPI screen and does not work well. I'll file a separate bug about that.
>
> test/jdk/java/awt/image/VolatileImage/ReportRenderingError.java line 61:
> 
>> 59:  *
>> 60:  * @requires (os.family == "mac")
>> 61:  * @run main/othervm -Dsun.java2d.opengl=True ReportRenderingError
> 
> I ran this test in macOS and without the fix it exits after checking only OpenGL pipeline. We dont override restoreContents() in CGLVolatileSurfaceManager/MTLVolatileSurfaceManager so its better if we can force the test to run on all pipelines on individual platforms and not exit on first failure based on jtreg instrcutions. This will make the test more robust.

This java file already contains 4 tests(each can be run/problemlists separately), one covers the default pipeline on all platforms, and the other 3 cover some platform specific just in case.

> test/jdk/java/awt/image/VolatileImage/ReportRenderingError.java line 91:
> 
>> 89:             Graphics2D g = vi.createGraphics();
>> 90:             g.setColor(Color.RED);
>> 91:             g.drawImage(image, 0, 0, null); // <- can cause InvalidPipeException
> 
> This drawImage call is expected to through InvalidPipeException all the times or is it intermittent?
> If it is intermittent why so? Please explain.
> 
> It looks like after https://github.com/openjdk/jdk/commit/8da6c8d6 we will through InvalidPipeException for all cases of custom images and not intermittently.

It is not really intermittent but depends on the java2d pipeline currently in use. InvalidPipeException is produced by the accelerated pipelines but code works fine on GDI for example.

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

PR: https://git.openjdk.org/jdk/pull/11664


From honkar at openjdk.org  Mon Feb  6 23:48:04 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 6 Feb 2023 23:48:04 GMT
Subject: Integrated: JDK-8289077: Add manual tests to open
In-Reply-To: <kv8B_v9d7UTlJ5aXORS5wKXoY_8zQhJtksWF8Z6UyJE=.47797585-a8ed-49e3-b6e1-76ecf88b5f91@github.com>
References: <kv8B_v9d7UTlJ5aXORS5wKXoY_8zQhJtksWF8Z6UyJE=.47797585-a8ed-49e3-b6e1-76ecf88b5f91@github.com>
Message-ID: <pUejnVVhiua_IOcn6fKqiX27PMqbUF9V_-nKIX71k2k=.ccd86b6c-0e63-41ca-9a88-0cc6e4a6314c@github.com>

On Mon, 6 Feb 2023 19:22:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Following manual tests added -
> 
> 1. test/jdk/java/awt/Frame/ALTTABIconBeingErased/ALTTABIconBeingErased.java
> 2. test/jdk/java/awt/Icon/IconChangingTest/IconChangingTest.java
> 3. test/jdk/java/awt/Icon/IconShowingTest/IconShowingTest.java
> 4. test/jdk/java/awt/Icon/IconTransparencyTest/IconTransparencyTest.java
> 5. test/jdk/java/awt/Icon/SetLargeIconTest/SetLargeIconTest.java

This pull request has now been integrated.

Changeset: 787e16bb
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/787e16bb444ee3b63803f5d1701d0f0a68b5d474
Stats:     945 lines in 7 files changed: 945 ins; 0 del; 0 mod

8289077: Add manual tests to open

Reviewed-by: azvegint

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

PR: https://git.openjdk.org/jdk/pull/12447


From dnguyen at openjdk.org  Mon Feb  6 23:57:04 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 6 Feb 2023 23:57:04 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
Message-ID: <RrIybjrvGmvm_uzSmbJusnwk4ofQevM21q2ZyH58Nnc=.ef7adef4-635d-4fba-9962-030bff944002@github.com>

On Mon, 6 Feb 2023 19:04:07 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused var. Fix try catch

@prsadhuk could you review this as well since I got your input about this issue previously? 

Initially, I thought it was the default value of the disabled combobox, but none of the skin.laf UI states/values affected the displayed text color.

So, it may be a state issue as you suggested. I checked the enabled state of each L&F, and the combobox's state is correct, but I noticed that the renderer in Synth has an additional condition that sets the renderer to disabled/enabled to match the combobox state. In testing, setting the renderer to disabled produced the correct behavior, so I made a listener as a workaround to access the combobox's renderer for the case with a DefaultListCellRenderer.

With the test I created, this approach creates the correct behavior, so I implemented the fix the cleanest way possible.

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

PR: https://git.openjdk.org/jdk/pull/12390


From ysuenaga at openjdk.org  Tue Feb  7 00:04:19 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Feb 2023 00:04:19 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I grep'ed (with `-i`) in `doc` directory with `LANG`, `utf`, `locale`, but I could not find out them. I guess locale of build environment is not mentioned clearly. Is it correct?

I agree with you to use English locale (e.g. `LANG=C`) is prefered, but I guess may difficult when we use WSL because `LANG` is not propergate to Windows environment.

I confirmed that it is succeeded to build with `--with-extra-cflags=/utf-8 --with-extra-cxxflags=/utf-8`, so I think it is better to add them to build option for Windows by default, but I'm not sure it is correct because no documents mention to the locale. What do you think?

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

PR: https://git.openjdk.org/jdk/pull/12436


From jwaters at openjdk.org  Tue Feb  7 00:52:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 00:52:26 GMT
Subject: RFR: 8301756: Missed constructor from 8301659 [v2]
In-Reply-To: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
References: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
Message-ID: <GvBQTJ5ncf_UGxp127p93uHbF9jXK39U1Ss2oZoKxsM=.d08af14b-d49b-4180-9d28-2b398164e4bf@github.com>

> 8301659 has missed a reordered constructor defined inside libawt

Julian Waters 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 patch-5
 - Reorder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12405/files
  - new: https://git.openjdk.org/jdk/pull/12405/files/b1f57e52..aae07b9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12405&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12405&range=00-01

  Stats: 5055 lines in 144 files changed: 3337 ins; 899 del; 819 mod
  Patch: https://git.openjdk.org/jdk/pull/12405.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12405/head:pull/12405

PR: https://git.openjdk.org/jdk/pull/12405


From prr at openjdk.org  Tue Feb  7 01:14:44 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Feb 2023 01:14:44 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
Message-ID: <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>

On Tue, 7 Feb 2023 00:01:56 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I grep'ed (with `-i`) in `doc` directory with `LANG`, `utf`, `locale`, but I could not find out them. I guess locale of build environment is not mentioned clearly. Is it correct?
> 
> I agree with you to use English locale (e.g. `LANG=C`) is prefered, but I guess may difficult when we use WSL because `LANG` is not propergate to Windows environment.
> 
> I confirmed that it is succeeded to build with `--with-extra-cflags=/utf-8 --with-extra-cxxflags=/utf-8`, so I think it is better to add them to build option for Windows by default, but I'm not sure it is correct because no documents mention to the locale. What do you think?

I don't know if it is documented but it has been discussed multiple times over the years.
Which encodings are *supposed* to work would be a good thing to document, LANG=C isn't strictly "English" and LC_* vars over-ride it
but "en_US-iso-8859-1" (eg) definitely should work, because that or some close equivalent (windows cp1252 or maybe 1250) are what we've considered as "must work" (SFAIK) 

If the build team want to make utf-8 the default encoding and it can be done  without having to worry unduly about 3rd party code and what might be in the repo today then that would be a good thing I expect.
But it is a bigger conversation than this PR

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

PR: https://git.openjdk.org/jdk/pull/12436


From jwaters at openjdk.org  Tue Feb  7 01:17:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 01:17:18 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

 - D3DVertexCacher.cpp
 - awt_List.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/24becec8..e6d54f21

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=03-04

  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

PR: https://git.openjdk.org/jdk/pull/12305


From honkar at openjdk.org  Tue Feb  7 02:18:45 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 7 Feb 2023 02:18:45 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
Message-ID: <RZdRuMq9cNHzYi7bhF22F-mav-xTQ99TwEjVOoZI1LY=.395b8216-d047-4af1-85a8-d6bc71941ca2@github.com>

On Mon, 6 Feb 2023 19:04:07 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused var. Fix try catch

Tested the fix on SwingSet2 and the fix works as expected. 
Copyright year needs to be updated for SynthComboBoxUI , DefaultListCellRenderer too.

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

Marked as reviewed by honkar (Committer).

PR: https://git.openjdk.org/jdk/pull/12390


From honkar at openjdk.org  Tue Feb  7 02:40:45 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 7 Feb 2023 02:40:45 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v5]
In-Reply-To: <9isfpPmDbm6x0J3OiEypPfSYS7UKhmHY1IVig8FWdq8=.3ca9af78-6ee2-4374-a593-4cebc2a2d8c3@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <9isfpPmDbm6x0J3OiEypPfSYS7UKhmHY1IVig8FWdq8=.3ca9af78-6ee2-4374-a593-4cebc2a2d8c3@github.com>
Message-ID: <Z5J_FUm4l9y7tyDe3CZwhYcJgKoD-dgXSeiZaT07T3o=.71c421be-2bb7-486b-888b-b94dc71d1f62@github.com>

On Mon, 6 Feb 2023 10:14:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
>> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
>> 
>> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
>> 
>> No regression test is added as it can be verified by SwingSet2 Tabledemo..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore set horiz/vert lines if showGrid is true by default

Marked as reviewed by honkar (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12385


From ysuenaga at openjdk.org  Tue Feb  7 02:48:44 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 7 Feb 2023 02:48:44 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
 <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
Message-ID: <UK4JI5dvB9AtHpcqTf3CW0TM7nEWxeF6txN8C-IUVxc=.7060f3fb-5e23-4e25-bc70-f431e4527fa5@github.com>

On Tue, 7 Feb 2023 01:12:06 GMT, Phil Race <prr at openjdk.org> wrote:

> but "en_US-iso-8859-1" (eg) definitely should work, because that or some close equivalent (windows cp1252 or maybe 1250) are what we've considered as "must work" (SFAIK)

According to Wikipedia article of [CP1250](https://en.wikipedia.org/wiki/Windows-1250) and [CP1252](https://en.wikipedia.org/wiki/Windows-1252), characters in 9x is not available in [8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1), and  I saw this error in `?` (0x93) and `?` (0x94).

So I think to use UTF-8 should be documented, and it is better to add `/utf-8` to `CFLAGS` / `CXXFLAGS` for Windows if we can.

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

PR: https://git.openjdk.org/jdk/pull/12436


From prr at openjdk.org  Tue Feb  7 03:58:41 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Feb 2023 03:58:41 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <UK4JI5dvB9AtHpcqTf3CW0TM7nEWxeF6txN8C-IUVxc=.7060f3fb-5e23-4e25-bc70-f431e4527fa5@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
 <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
 <UK4JI5dvB9AtHpcqTf3CW0TM7nEWxeF6txN8C-IUVxc=.7060f3fb-5e23-4e25-bc70-f431e4527fa5@github.com>
Message-ID: <nXvj-1SdQOXY7BFgVRrsGj5ItlbUehknEiAKKVCkZac=.ee391d1d-294c-4870-b626-ccdd839226be@github.com>

On Tue, 7 Feb 2023 02:46:10 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> > but "en_US-iso-8859-1" (eg) definitely should work, because that or some close equivalent (windows cp1252 or maybe 1250) are what we've considered as "must work" (SFAIK)
> 
> According to Wikipedia article of [CP1250](https://en.wikipedia.org/wiki/Windows-1250) and [CP1252](https://en.wikipedia.org/wiki/Windows-1252), characters in 9x is not available in [8859-1](https://en.wikipedia.org/wiki/ISO/IEC_8859-1), and I saw this error in `?` (0x93) and `?` (0x94).
> 
> So I think to use UTF-8 should be documented, and it is better to add `/utf-8` to `CFLAGS` / `CXXFLAGS` for Windows if we can.

So let's say it is the compatible subset.

Regardless, take this to the build team as a separate PR to find a JDK-wide
solution. No disabling warnings in random libraries

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

PR: https://git.openjdk.org/jdk/pull/12436


From prr at openjdk.org  Tue Feb  7 04:10:45 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Feb 2023 04:10:45 GMT
Subject: RFR: 8301756: Missed constructor from 8301659 [v2]
In-Reply-To: <GvBQTJ5ncf_UGxp127p93uHbF9jXK39U1Ss2oZoKxsM=.d08af14b-d49b-4180-9d28-2b398164e4bf@github.com>
References: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
 <GvBQTJ5ncf_UGxp127p93uHbF9jXK39U1Ss2oZoKxsM=.d08af14b-d49b-4180-9d28-2b398164e4bf@github.com>
Message-ID: <2uOmZcfd5fl6OerMwEs7v-hLzN6hc-NazrHyn5IpOzY=.9c548758-ef62-41d3-a512-232227f30f23@github.com>

On Tue, 7 Feb 2023 00:52:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8301659 has missed a reordered constructor defined inside libawt
>
> Julian Waters 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 patch-5
>  - Reorder

1) How did you miss this ?
2) Bigger question, why is it important ? We are never going to support gcc for compiling on Windows .. no one is going to care if it breaks and no one is going to put any effort into making sure it works at all. Not until the day Microsoft replaces VC with gcc ..

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

PR: https://git.openjdk.org/jdk/pull/12405


From jdv at openjdk.org  Tue Feb  7 05:09:45 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 7 Feb 2023 05:09:45 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v5]
In-Reply-To: <2VwBZ7updndz-IQpRPzIMbCtigNqjiYR30iZX2REcWg=.ad216634-0a88-467e-9a78-bf7c87ed1c32@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <2VwBZ7updndz-IQpRPzIMbCtigNqjiYR30iZX2REcWg=.ad216634-0a88-467e-9a78-bf7c87ed1c32@github.com>
Message-ID: <SrucCKj-sjenIGodXq5PflpUt_FPp4cd3rdIAS0ho4k=.865fc042-80c5-4e5c-a6a8-d83f43b176d2@github.com>

On Fri, 3 Feb 2023 20:24:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncommented portion of test

I don't have old Macbook Pro on which i verified previously but on my latest Macbook Pro the updated test passes multiple times.

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

Marked as reviewed by jdv (Reviewer).

PR: https://git.openjdk.org/jdk/pull/10363


From djelinski at openjdk.org  Tue Feb  7 08:01:48 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 7 Feb 2023 08:01:48 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v2]
In-Reply-To: <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
Message-ID: <vJetAJWOKG6XLWPgcTRbViLLFBHZR7FsDol0oOYV5v0=.6a71b07b-a7ee-4ad4-ad15-eb29e4732f51@github.com>

On Fri, 20 Jan 2023 12:01:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
>> 
>> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>  - Copyright
>  - snprintf
>  - cl analyze
>  - Fix non-debug warning
>  - Restore suppressions
>  - Fix warnings
>  - WIP: reenable awt warnings
>  - Fix warnings

keep alive / waiting for review from client-libs...

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

PR: https://git.openjdk.org/jdk/pull/11841


From psadhukhan at openjdk.org  Tue Feb  7 08:18:47 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 7 Feb 2023 08:18:47 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
Message-ID: <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>

On Mon, 6 Feb 2023 19:04:07 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused var. Fix try catch

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java#L552-L558
The present code SynthComboBoxRenderer  does enable/disable the listcell renderer based on comboBox status, why it is not working? why do we need to use a listener for DefaultListCellRenderer?

Also, I think it will be better to make the test automated..something like draw comboBox content into BufferedImage and pixel compare if it is same for disabled/enabled and fail if they are same

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

PR: https://git.openjdk.org/jdk/pull/12390


From ihse at openjdk.org  Tue Feb  7 11:52:46 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 11:52:46 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
 <n-MsdlWZLOp2kJXN4tSEtNirAacsqv3XVwsKysNX4yY=.f96a013a-817b-4f78-aa6c-59a00c6ee6d9@github.com>
 <mGBFJRL2_EMkqGliLM9VqWQj6qDYcfHYNFGLc_NNn8E=.ca1df3b3-f1b7-406b-bb3d-6f8593c9c417@github.com>
Message-ID: <NDB4tmeUbWLGlY55m29B4qpy4jXAMzinhoxXLX0Pqlw=.3b4e2fce-d963-4767-8881-6a55d1a3d3ba@github.com>

On Tue, 7 Feb 2023 01:12:06 GMT, Phil Race <prr at openjdk.org> wrote:

> I grep'ed (with `-i`) in `doc` directory with `LANG`, `utf`, `locale`, but I could not find out them. I guess locale of build environment is not mentioned clearly. Is it correct?

Yes, it is unfortunately not documented. :-( There is an open bug about this ([JDK-8264425](https://bugs.openjdk.org/browse/JDK-8264425)) but it has repeatedly been pushed down on my todo list due to low priority. :(

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

PR: https://git.openjdk.org/jdk/pull/12436


From ihse at openjdk.org  Tue Feb  7 11:59:45 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 11:59:45 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <_c9E5NjAP1NXGjDBcuLK3cMb-F_DI27WO3f2wtYPlnI=.cf39aef7-1504-4478-9b5b-abf17bef9afd@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I agree with Phil here. This is not the proper solution. As a workaround, you can use the configure arguments to add additional flags to the compiler. Or you can change your locale.

The proper solution is getting the source code base to a consistent UTF-8 format. This is a much larger undertaking, however.

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

Changes requested by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12436


From ihse at openjdk.org  Tue Feb  7 12:00:47 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 12:00:47 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <B4S0VaqCh7hyA54qS7s2bk31jNO6ROzXj5MWKKgCi4U=.927f12a6-6b84-401f-8c71-df6c59dd8225@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

Please do not integrate this. See the other sub-tasks for discussion.

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

Changes requested by ihse (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12437


From ihse at openjdk.org  Tue Feb  7 12:11:44 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Feb 2023 12:11:44 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <iqoT-P1QSo3PVg9vM1cscwbmzFKUoN6wGxSIgA21lEs=.659ffe3e-274f-4c3e-bd7f-8fcfca9c79b0@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

I have opened https://bugs.openjdk.org/browse/JDK-8301971 for converting the entire code base to UTF-8.

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

PR: https://git.openjdk.org/jdk/pull/12436


From jwaters at openjdk.org  Tue Feb  7 13:52:49 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 13:52:49 GMT
Subject: RFR: 8301756: Missed constructor from 8301659 [v2]
In-Reply-To: <2uOmZcfd5fl6OerMwEs7v-hLzN6hc-NazrHyn5IpOzY=.9c548758-ef62-41d3-a512-232227f30f23@github.com>
References: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
 <GvBQTJ5ncf_UGxp127p93uHbF9jXK39U1Ss2oZoKxsM=.d08af14b-d49b-4180-9d28-2b398164e4bf@github.com>
 <2uOmZcfd5fl6OerMwEs7v-hLzN6hc-NazrHyn5IpOzY=.9c548758-ef62-41d3-a512-232227f30f23@github.com>
Message-ID: <h1XudUMZWfGe4XtfjSYk5LeFEYfnvMgHDdavNvYZdQA=.35633035-02c8-4842-bb6f-0b7bd91327de@github.com>

On Tue, 7 Feb 2023 04:08:09 GMT, Phil Race <prr at openjdk.org> wrote:

> How did you miss this ?

Oversight, my mistake, it happens sometimes



> Bigger question, why is it important ?

Code quality, constructors in C++ should generally have the initializer list in the same order as their declaration. It helps deduce class layout and initialization order at a quick glance when reviewing code with the constructor in an implementation file away from the class itself, as is the case here, ignoring everything about gcc (You could very easily disable the warning on this file in Awt2dLibraries and be done with it instead if you really wanted to anyway, but I don't think it's good to do that). Common pitfalls in C++ should really be avoided when it comes to JDK code as a whole (consistency is also another reason), or at least that's my opinion. Convention within the JDK has largely been to initialize class members in the correct order too, which is what this patch intends to help with



> ...no one is going to care if it breaks and no one is going to put any effort into making sure it works at all.

[What makes you](https://bugs.openjdk.org/browse/JDK-8288293) [so sure](https://github.com/TheShermanTanker/jdk/tree/compiler)?

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

PR: https://git.openjdk.org/jdk/pull/12405


From aivanov at openjdk.org  Tue Feb  7 15:34:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 15:34:17 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
Message-ID: <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>

On Tue, 7 Feb 2023 01:17:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - D3DVertexCacher.cpp
>  - awt_List.cpp

src/java.desktop/windows/native/libawt/windows/awt_List.cpp line 183:

> 181: //      SetWindowPos(hList, 0, 0, 0, w, h, flags);
> 182: //  }
> 183: //

Maybe it's time to remove this commented out code? It's been commented out since 2007 when the code moved to Mercurial.

If you decide to remove it, please submit a new issue to communicate the intention clearly.

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

PR: https://git.openjdk.org/jdk/pull/12305


From aivanov at openjdk.org  Tue Feb  7 15:34:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 15:34:20 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v2]
In-Reply-To: <SI9ksB_ugdnmIP9OF3CPWqM_HDjZcHyLlwmsg8L6oiY=.b3114edb-bbfe-48f0-a086-39f79f713f6b@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <7T2Nhag_cpvDUJuCDtGzb9SYlkB97oNX0iiLBl1CSmo=.2f850290-24e9-4c87-83c4-a964f1d859f4@github.com>
 <qG3PDK_Rdib3rla7KWE9lAjLaejYIVFdP1hOZS7iHgY=.bb00f225-cdb2-41c9-826d-dc6fc575b473@github.com>
 <IB4Ym1IMKPT3VaF8l86vl6j94Uyo1khWDEATWwm3hFM=.512c9f14-b656-4408-8e75-74dfeb171467@github.com>
 <BSFgEA_dNzUovcyWibbl3Fj6FgDB0b-IsDC27x-ZZVc=.f1c2c0d5-0421-4ebe-954a-ca85ec9a41ba@github.com>
 <EYvqgKGXM-a-WvZ3bCCUxDKm7LAwEUMGIaJlLgPKP_M=.da460763-a0bb-4928-95af-7d09ee4b12a1@github.com>
 <OLY14ygQ7c06OohYjgfuKmWUkyekbxMKe2ggreclk8A=.ea881ecb-e0be-4c83-b569-044a1c5d641a@github.com>
 <284HM_Bi7YrRDIurHMJhjEDiXnuUTQNpTRxOaaDXOo4=.3a96b35a-fac4-4755-9c0d-893e5506df30@github.com>
 <SI9ksB_ugdnmIP9OF3CPWqM_HDjZcHyLlwmsg8L6oiY=.b3114edb-bbfe-48f0-a086-39f79f713f6b@github.com>
Message-ID: <DEFA3KIoARIe_UKINva75oSfK82gywHUx7-ZaFfySuk=.0e32de96-44c3-4e4b-b377-6d412a6b2855@github.com>

On Mon, 6 Feb 2023 03:31:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> I don't know. I'm quite sure I was using the full command in `cmd.exe` after calling some `vcvars64.bat`. I added the `` character because it's a little long to be recorded here. I don't really care which separator is used. You can remove the `` character. We don't need to spend too much time on this.
>
> Honestly, with all of this confusion around the command line, I think I'd rather just avoid the issue entirely by turning this into a multiline comment so the backslash doesn't cause compiler warnings

I don't know what the error message you get, but `^` definitely works for me as continuation line marker in `cmd.exe`.


C:\dev\jdk-dev>cl -I %OPENJDK%\src\java.security.jgss\share\native\libj2gss\ sspi.cpp ^
More?    -link -dll -out:sspi_bridge.dll
'cl' is not recognized as an internal or external command,
operable program or batch file.


This `More?` prompt identifies the continuation line.

Anyway, we decided to leave it as is but convert to multi-line comment, which is fine with me.

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

PR: https://git.openjdk.org/jdk/pull/12305


From jwaters at openjdk.org  Tue Feb  7 16:00:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 16:00:09 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
Message-ID: <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>

On Tue, 7 Feb 2023 15:14:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - D3DVertexCacher.cpp
>>  - awt_List.cpp
>
> src/java.desktop/windows/native/libawt/windows/awt_List.cpp line 183:
> 
>> 181: //      SetWindowPos(hList, 0, 0, 0, w, h, flags);
>> 182: //  }
>> 183: //
> 
> Maybe it's time to remove this commented out code? It's been commented out since 2007 when the code moved to Mercurial.
> 
> If you decide to remove it, please submit a new issue to communicate the intention clearly.

Perhaps, but I'll leave that to the discretion of the client libs group. Are the new changes fine with you though?

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

PR: https://git.openjdk.org/jdk/pull/12305


From aivanov at openjdk.org  Tue Feb  7 16:14:56 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 16:14:56 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
Message-ID: <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>

On Tue, 7 Feb 2023 15:57:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_List.cpp line 183:
>> 
>>> 181: //      SetWindowPos(hList, 0, 0, 0, w, h, flags);
>>> 182: //  }
>>> 183: //
>> 
>> Maybe it's time to remove this commented out code? It's been commented out since 2007 when the code moved to Mercurial.
>> 
>> If you decide to remove it, please submit a new issue to communicate the intention clearly.
>
> Perhaps, but I'll leave that to the discretion of the client libs group. Are the new changes fine with you though?

I'd rather remove the offending commented out code than change its formatting.

Could you submit a bug, please, and assign it to me?

There's a closed test associated with [JDK-4046446](https://bugs.openjdk.org/browse/JDK-4046446), it can be open-sourced. Then it'll be safe to remove the commented out code.

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

PR: https://git.openjdk.org/jdk/pull/12305


From dnguyen at openjdk.org  Tue Feb  7 17:05:44 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 7 Feb 2023 17:05:44 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
 <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>
Message-ID: <NndterQASTmoDb-A5Wj2ZDRfH6GtOaF4SFhAFg21wVM=.c48203de-5abe-4d0e-a000-b9fa6c7b8684@github.com>

On Tue, 7 Feb 2023 08:15:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> https://github.com/openjdk/jdk/blob/98433a2f6e7fe97e03ed26673c9925d7b26466bf/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java#L552-L558
> 
> The present code SynthComboBoxRenderer does enable/disable the listcell renderer based on comboBox status, why it is not working? why do we need to use a listener for DefaultListCellRenderer?
> 
> Also, I think it will be better to make the test automated..something like draw comboBox content into BufferedImage and pixel compare if it is same for disabled/enabled and fail if they are same and iterate for all L&Fs as it will also affect GTK as per the comment

The setEnabled line you mentioned in SynthComboBoxUI applies to SynthComboBoxRenderer only. This issue only occurs when DefaultListCellRenderer is used for a disabled Nimbus ComboBox instead of the default renderer for Nimbus (SynthComboBoxRenderer). So this code is never reached.

I will work on making the test automated instead if preferred.

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

PR: https://git.openjdk.org/jdk/pull/12390


From jwaters at openjdk.org  Tue Feb  7 17:11:08 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Feb 2023 17:11:08 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
Message-ID: <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>

On Tue, 7 Feb 2023 16:11:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Perhaps, but I'll leave that to the discretion of the client libs group. Are the new changes fine with you though?
>
> I'd rather remove the offending commented out code than change its formatting.
> 
> Could you submit a bug, please, and assign it to me?
> 
> There's a closed test associated with [JDK-4046446](https://bugs.openjdk.org/browse/JDK-4046446), it can be open-sourced. Then it'll be safe to remove the commented out code.

Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994

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

PR: https://git.openjdk.org/jdk/pull/12305


From aivanov at openjdk.org  Tue Feb  7 17:20:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 17:20:09 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v13]
In-Reply-To: <OZNhKFK-aQRDBye3AE_6SqkeC_edGS0rTn_GyyqM5Ug=.117e492d-bb7e-40f4-ac7e-c99861975677@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <OZNhKFK-aQRDBye3AE_6SqkeC_edGS0rTn_GyyqM5Ug=.117e492d-bb7e-40f4-ac7e-c99861975677@github.com>
Message-ID: <QsSZCEUWZ4oAi4u7p1g2gM_FVg1UK55IHT1cw6DATzY=.40a01aa3-f4d2-454b-96e2-56e92ac06a52@github.com>

On Fri, 3 Feb 2023 14:13:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Spec wording modified

The changes to the spec look go to me.

Since a CSR is required, I suggest updating the spec for `isDone` method so that it returns `true` only after `doInBackground` exits. Now `isDone` returns `true` after `cancel` completes but the `DONE` state isn't reached yet.

I think this change will make the implementation more consistent is easier to use.

As for the test, it does not ensure the `STARTED` state is notified before `doInBackground` started running, nor does it ensure `DONE` state is notified before `done` method is called.

Isn't it what we want to test?

If I run the test with jdk19 and comment out the `throw` statement in `done`, the test passes. Yet I expect it to fail since the order of notification about `DONE` state and `done` call is reversed in the fix.

Or do you both think it's too much for the test?

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 35:

> 33: import java.util.concurrent.CountDownLatch;
> 34: import java.util.concurrent.TimeUnit;
> 35: import java.util.concurrent.atomic.AtomicBoolean;

`AtomicBoolean` isn't currently used.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 39:

> 37: public class TestDoneBeforeDoInBackground {
> 38: 
> 39:     private static boolean doInBackground = false;

Suggestion:

    private static volatile boolean doInBackground = false;

It still needs to be `volatile`, it's consistently accessed from three different threads.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 70:

> 68:             protected void done() {
> 69:                 if (!doInBackground) {
> 70:                     throw new RuntimeException("done called before doInBackground");

Suggestion:

                    throw new RuntimeException("done called before doInBackground finished");

Otherwise, it looks very confusing.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 92:

> 90:                     }
> 91:                     // After the doInBackground method is finished
> 92:                     // SwingWorker} notifies PropertyChangeListeners

Suggestion:

                    // SwingWorker notifies PropertyChangeListeners

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 97:

> 95:                             worker.getState() != SwingWorker.StateValue.DONE) {
> 96:                         throw new RuntimeException(
> 97:                             "listener called after doInBackground is finised" +

Suggestion:

                            "PropertyChangeListeners called after doInBackground is finished" +

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11940


From alexsch at openjdk.org  Tue Feb  7 17:20:19 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 7 Feb 2023 17:20:19 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v3]
In-Reply-To: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
Message-ID: <-tpYJcPxbkQ6zMPv51AJR3aJFo809DTtMynt3qAvdgQ=.5e8f5be3-33f7-4663-87b6-66cf78e726ca@github.com>

> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
> 
> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
> 
> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
> 
> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
> 
> Steps to reproduce.
> - Download Oracle jdk-19.0.2
> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
> 
> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
> zypper install -y dejavu-fonts
> zypper install -y freetype2
> 
> - Run HelloImage java sample in the docker
> 
> import javax.imageio.ImageIO;
> import java.awt.*;
> import java.awt.image.BufferedImage;
> import java.io.File;
> 
> public class HelloImage {
> 
>     public static void main(String[] args) throws Exception {
> 
>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>         Graphics2D g = buff.createGraphics();
>         g.setColor(Color.WHITE);
>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
> 
>         g.setColor(Color.BLUE);
>         g.setFont(g.getFont().deriveFont(32f));
>         g.drawString("Hello, Image!", 50, 50);
>         g.dispose();
> 
>         File file = new File("hello-image.png");
>         ImageIO.write(buff, "png", file);
>     }
> }
> 
> 
> 
> ./jdk-19.0.2/bin/javac HelloImage.java
> ./jdk-19.0.2/bin/java HelloImage
> Exception in thread "main" java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
> 	at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1261)
> 	at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:221)
> 	at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:105)
> 	at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
> 	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:352)
> 	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:309)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
> 	at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:309)
> 	at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
> 	at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
> 	at java.desktop/java.awt.Font.getFont2D(Font.java:526)
> 	at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
> 	at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:151)
> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
> 	at HelloImage.main(HelloImage.java:17)

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

  Extract os name as ID from /etc/os-release file for fonts configuration

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12260/files
  - new: https://git.openjdk.org/jdk/pull/12260/files/ba04df3f..d1d7f2f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12260&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12260&range=01-02

  Stats: 28 lines in 2 files changed: 12 ins; 4 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12260.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12260/head:pull/12260

PR: https://git.openjdk.org/jdk/pull/12260


From alexsch at openjdk.org  Tue Feb  7 18:16:06 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 7 Feb 2023 18:16:06 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v3]
In-Reply-To: <-tpYJcPxbkQ6zMPv51AJR3aJFo809DTtMynt3qAvdgQ=.5e8f5be3-33f7-4663-87b6-66cf78e726ca@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <-tpYJcPxbkQ6zMPv51AJR3aJFo809DTtMynt3qAvdgQ=.5e8f5be3-33f7-4663-87b6-66cf78e726ca@github.com>
Message-ID: <YXjGYYTXZiqfgWVh42ShT9HWOwvwabKkfPYq3L9Nf4o=.9e6b7045-a5e5-4865-a720-9b0c41e7729a@github.com>

On Tue, 7 Feb 2023 17:20:19 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
>> 
>> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
>> 
>> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
>> 
>> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
>> 
>> Steps to reproduce.
>> - Download Oracle jdk-19.0.2
>> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
>> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
>> 
>> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
>> zypper install -y dejavu-fonts
>> zypper install -y freetype2
>> 
>> - Run HelloImage java sample in the docker
>> 
>> import javax.imageio.ImageIO;
>> import java.awt.*;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> 
>> public class HelloImage {
>> 
>>     public static void main(String[] args) throws Exception {
>> 
>>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>>         Graphics2D g = buff.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
>> 
>>         g.setColor(Color.BLUE);
>>         g.setFont(g.getFont().deriveFont(32f));
>>         g.drawString("Hello, Image!", 50, 50);
>>         g.dispose();
>> 
>>         File file = new File("hello-image.png");
>>         ImageIO.write(buff, "png", file);
>>     }
>> }
>> 
>> 
>> 
>> ./jdk-19.0.2/bin/javac HelloImage.java
>> ./jdk-19.0.2/bin/java HelloImage
>> Exception in thread "main" java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
>> 	at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1261)
>> 	at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:221)
>> 	at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:105)
>> 	at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
>> 	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:352)
>> 	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:309)
>> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> 	at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:309)
>> 	at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
>> 	at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
>> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
>> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
>> 	at java.desktop/java.awt.Font.getFont2D(Font.java:526)
>> 	at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
>> 	at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:151)
>> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
>> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
>> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
>> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
>> 	at HelloImage.main(HelloImage.java:17)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract os name as ID from /etc/os-release file for fonts configuration

Could you review the updated fix?

- `ID` property from `/etc/os-release` file is used for os name when the `/etc/os-release` file is handled.
- `NAME` property for `SUSE` check is left as is to not break the [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549) fix.
- `extractOsInfo()` method is renamed to `extractInfo()`. It now checks the input string to null and replaces white characters to underscores.
- There are operation systems that have both `/etc/lsb-release` and `/etc/os-release` files. For example, Photon OS have:

`/etc/os-release`

NAME="VMware Photon OS"
ID=photon
VERSION_ID=4.0

`/etc/lsb-release`

DISTRIB_ID="VMware Photon OS"
DISTRIB_RELEASE="4.0"

The `extractInfo()` method is added for os name/version parsing during `/etc/lsb-release` file handling as well.

Some improvements can be added.
- May be it has sense to allow to configure os name for `fontconfig.properties` file by a Java property. It allows to use a simple custom os name in the `fontconfig.properties` and reuse the same property file on several systems like SLES, openSUSE Leap, and openSUSE Tumbleweed.
- Running a java program with `-Dsun.java2d.debugfonts=true` property lists checked `fontconfig.properties` files:

INFO: Looking for text fontconfig file : /build/jdk/images/jdk/lib/fontconfig.opensuse-leap.15.4.properties
Feb 07, 2023 5:43:30 PM sun.awt.FontConfiguration findImpl
INFO: Looking for binary fontconfig file : /build/jdk/images/jdk/lib/fontconfig.opensuse-leap.15.4.bfc
Feb 07, 2023 5:43:30 PM sun.awt.FontConfiguration findImpl

It could be a good idea to add logging for os name and version in `setOsNameAndVersion()` method as well.
- The code for os name/version detection is duplicated in FcFontConfiguration and MFontConfiguration classes. It would be good to unify them. Though they have different files parsing order:

FcFontConfiguration: `lsb-release, redhat-release, SuSE-release, turbolinux-release, fedora-release, os-release`
MFontConfiguration: `fedora-release, redhat-release, turbolinux-release, SuSE-release, lsb-release`

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

PR: https://git.openjdk.org/jdk/pull/12260


From aivanov at openjdk.org  Tue Feb  7 19:22:32 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 19:22:32 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
 <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
Message-ID: <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>

On Tue, 7 Feb 2023 17:08:07 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994

Thank you, @TheShermanTanker.

Do you still want to keep the changes?
If it's not too critical, I would rather prefer you revert the changes to `awt_List.cpp`.

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

PR: https://git.openjdk.org/jdk/pull/12305


From achung at openjdk.org  Tue Feb  7 20:32:38 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 7 Feb 2023 20:32:38 GMT
Subject: Integrated: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0
In-Reply-To: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
Message-ID: <6Dn9VexNxB8nZ2KaLtbXdiCB6bbaFHWuAwX0AZ8NOQI=.14a1efcb-e577-49b2-be82-69095bd4a33c@github.com>

On Tue, 20 Sep 2022 18:24:26 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete

This pull request has now been integrated.

Changeset: 2a579ab8
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a579ab8392d30a35f044954178c788d16d4b800
Stats:     15 lines in 2 files changed: 15 ins; 0 del; 0 mod

8292588: [macos] Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java: Robot.mouseMove test failed on Screen #0

Reviewed-by: dnguyen, jdv

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

PR: https://git.openjdk.org/jdk/pull/10363


From aivanov at openjdk.org  Tue Feb  7 20:39:15 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 20:39:15 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v5]
In-Reply-To: <6nalpkM3XvpxqLFZ2A_fCLy4EdzwHwYSXMedLUWCOoU=.d403d0c1-6ce5-4776-b9a0-012cff735f8f@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <6nalpkM3XvpxqLFZ2A_fCLy4EdzwHwYSXMedLUWCOoU=.d403d0c1-6ce5-4776-b9a0-012cff735f8f@github.com>
Message-ID: <Q1fBhJQZ1g4CrHc4tWDgYOeG5ytqmuKGqdvW3CRVh3o=.d64ff5c3-24d5-4ba8-9cbf-b464cbb559a5@github.com>

On Mon, 6 Feb 2023 09:24:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
>> says:
>> "...MetalLookAndFeel registers an entry for each of the classes
>> in the package javax.swing.plaf.metal that are named MetalXXXUI.
>> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
>> that do not have a class in metal, the corresponding class in
>> javax.swing.plaf.basic is used. For example, metal does not
>> have a class named "MetalColorChooserUI", as such,
>> javax.swing.plaf.basic.BasicColorChooserUI is used".
>> 
>> There is class MetalMenuBarUI, but the method populates given defaults table with the value
>> "javax.swing.plaf.basic.BasicMenuBarUI".
>> 
>> Added entry for MetalMenuBarUI..
>> CI tests including JCK tests are ok.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add MetalMenuBarUI in MetalL&F

Marked as reviewed by aivanov (Reviewer).

Is there really only Ocean theme? If I start SwingSet2, there are a handful of Metal themes under **Theme** menu.

If I change the theme, the colours of the menu bar also change.

What happens if I use a different theme instead of the default Ocean?

It's possible by passing `-Dswing.metalTheme=steel`. The menu bar is still styled.

So it looks all Metal themes use `MetalMenuBarUI`. As such, moving the registration of `MenuBarUI` class id from `OceanTheme` to `MetalLookAndFeel` makes sense. Especially, taking into account that javadoc for `MetalMenuBarUI` states, it ?is responsible for the metal look and feel of `JMenuBar`s.?

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

PR: https://git.openjdk.org/jdk/pull/11646


From aivanov at openjdk.org  Tue Feb  7 20:55:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 20:55:57 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v4]
In-Reply-To: <M7gsh2iBq4e1-FiOlDnZhVtcugPt-p4Es9IX2oWbVD0=.d9739dc1-686f-40e1-bcc0-aabebbf33bcd@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
 <M7gsh2iBq4e1-FiOlDnZhVtcugPt-p4Es9IX2oWbVD0=.d9739dc1-686f-40e1-bcc0-aabebbf33bcd@github.com>
Message-ID: <EsuGCA4AIXvTyGOyz7hRKpQ1nepXeoGX7a4xo9xE-oc=.78ccb3a2-5752-4724-afcd-6e85dfca13f2@github.com>

On Fri, 3 Feb 2023 22:43:22 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
>> 
>> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.
>
> 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:
> 
>  - review changes: AbstractMetalWindowBorder, strokeWidth rename
>  - Merge branch 'master' into MetalBorderRefactor_8294484
>  - minor change
>  - removed unused import
>  - added updateColor(), isActive() to MetalBorder
>  - test summary changes
>  - deleted InternalFrameBorderTest
>  - moved corner var to AbstractMetalBorder
>  - sealed abstract class, record changes
>  - initial commit, consolidated test case

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 281:

> 279: 
> 280:             // scaled thickness
> 281:             int thickness = (int) Math.ceil(4 * scaleFactor);

Suggestion:

            updateColors(c);

            // scaled thickness
            int thickness = (int) Math.ceil(4 * scaleFactor);
            g.setColor(background);

Setting the background color logically belongs to painting the bulk of the border rather than updating the colors.

src/java.desktop/share/classes/javax/swing/plaf/metal/MetalBorders.java line 376:

> 374:         public Insets getBorderInsets(Component c, Insets newInsets) {
> 375:             newInsets.set(4, 4, 4, 4);
> 376:             return newInsets;

For consistency with compositing the implementation, it should be:
Suggestion:

            return border.getInsets(newInsets);

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

PR: https://git.openjdk.org/jdk/pull/12391


From aivanov at openjdk.org  Tue Feb  7 20:55:59 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Feb 2023 20:55:59 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v3]
In-Reply-To: <l6App-tx9TJTqNZbOkQLDlfvGoBkofQdbDdeIlopuGI=.ebd38164-9718-4a9e-b09d-87fb9b597422@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
 <3y2rUWBiNMz68tvWWzJzFB_2NSdsZsygQXyRL2i8cpg=.9ac1c098-ddaa-46b5-acc8-6274ec0a9b59@github.com>
 <VDvf5kevvU0B-rH4HuXPDpMV8XexxgB9BQdWFyRMj1w=.54b4579a-4dd6-4c30-acbc-94ac08012dac@github.com>
 <l6App-tx9TJTqNZbOkQLDlfvGoBkofQdbDdeIlopuGI=.ebd38164-9718-4a9e-b09d-87fb9b597422@github.com>
Message-ID: <RQDe7zrkv3Ua0RU5qczJk7HxgyAWetgjo4zLCKQ0Efw=.2a793711-f627-4d68-8a4f-c7030b38ecc2@github.com>

On Fri, 3 Feb 2023 22:10:47 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Since `isResizable` has to be overridden in this case too, retaining the original class hierarchy.

Reasonable, thanks.

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

PR: https://git.openjdk.org/jdk/pull/12391


From honkar at openjdk.org  Tue Feb  7 21:57:16 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 7 Feb 2023 21:57:16 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v5]
In-Reply-To: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
Message-ID: <MlEUPB2T45M5xgVlYahStFtJX-iZV2hW2z_RJUnJdwE=.93193e6e-0444-4517-a4fc-edb4e6c6f8e1@github.com>

> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
> 
> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.

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 12 additional commits since the last revision:

 - minor review changes
 - Merge branch 'master' into MetalBorderRefactor_8294484
 - review changes: AbstractMetalWindowBorder, strokeWidth rename
 - Merge branch 'master' into MetalBorderRefactor_8294484
 - minor change
 - removed unused import
 - added updateColor(), isActive() to MetalBorder
 - test summary changes
 - deleted InternalFrameBorderTest
 - moved corner var to AbstractMetalBorder
 - ... and 2 more: https://git.openjdk.org/jdk/compare/efb47057...e9b37edc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12391/files
  - new: https://git.openjdk.org/jdk/pull/12391/files/4be01e84..e9b37edc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12391&range=03-04

  Stats: 1994 lines in 12 files changed: 1245 ins; 734 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/12391.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12391/head:pull/12391

PR: https://git.openjdk.org/jdk/pull/12391


From kizune at openjdk.org  Tue Feb  7 22:56:47 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 7 Feb 2023 22:56:47 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE
Message-ID: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>

Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.

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

Commit messages:
 - 8301989: new javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE

Changes: https://git.openjdk.org/jdk20/pull/122/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk20&pr=122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301989
  Stats: 48 lines in 2 files changed: 46 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk20/pull/122.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/122/head:pull/122

PR: https://git.openjdk.org/jdk20/pull/122


From prr at openjdk.org  Tue Feb  7 23:10:54 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Feb 2023 23:10:54 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE
In-Reply-To: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
Message-ID: <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>

On Tue, 7 Feb 2023 22:49:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.

src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 1054:

> 1052:         if (rate != 0) {
> 1053:             if (component != null && component.isEditable()) {
> 1054:                 if (flasher == null) {

So later if there is a non-editable component, what happens ?
Some existing logic for that will kick in ?

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

PR: https://git.openjdk.org/jdk20/pull/122


From dnguyen at openjdk.org  Tue Feb  7 23:14:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 7 Feb 2023 23:14:23 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v5]
In-Reply-To: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
Message-ID: <-owWLhz4rfTDxRWUPkzPSTwOog6of3OiEIFSbdiSrgM=.4a953820-b264-405e-be03-0bed8fce70e3@github.com>

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

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

  Update years. Add conditional

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12390/files
  - new: https://git.openjdk.org/jdk/pull/12390/files/99286089..cdbc9a89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/12390


From kizune at openjdk.org  Tue Feb  7 23:18:50 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 7 Feb 2023 23:18:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE
In-Reply-To: <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>
Message-ID: <k936iKtvEA2hePHELvYlZyuhxywnnYnPiGC7a54J0AQ=.b72ff6c6-dd09-4a21-8926-880641e8620c@github.com>

On Tue, 7 Feb 2023 23:07:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.
>
> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 1054:
> 
>> 1052:         if (rate != 0) {
>> 1053:             if (component != null && component.isEditable()) {
>> 1054:                 if (flasher == null) {
> 
> So later if there is a non-editable component, what happens ?
> Some existing logic for that will kick in ?

Yes, when the the caret is to be assigned to a component it will reset the blink rate and the logic will kick in. Manually tested with the possible scenarios like adding custom set blink rate cursor to a non-editable component and then turn it into editable later, add to editable and switch to non-editable later and so on.

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Tue Feb  7 23:23:24 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 7 Feb 2023 23:23:24 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
Message-ID: <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>

> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.

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

  Fixe copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk20/pull/122/files
  - new: https://git.openjdk.org/jdk20/pull/122/files/81978ac4..bfb308dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk20&pr=122&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk20&pr=122&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk20/pull/122.diff
  Fetch: git fetch https://git.openjdk.org/jdk20 pull/122/head:pull/122

PR: https://git.openjdk.org/jdk20/pull/122


From dnguyen at openjdk.org  Wed Feb  8 00:04:50 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 8 Feb 2023 00:04:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
Message-ID: <G9w8ymA0LkXUaTk8zVi1ltsaa_EpUcHMQ89NYP9EDR4=.5157444b-1360-49d2-a367-8e6c7f4c754d@github.com>

On Tue, 7 Feb 2023 23:23:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixe copyright year.

The changes seem to fix the NPE as expected. When testing, the provided test fails before the patch and passes after the patch is applied.

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

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk20/pull/122


From honkar at openjdk.org  Wed Feb  8 00:25:44 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 8 Feb 2023 00:25:44 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
Message-ID: <ehVMIggFfRBcRKUd7KTEGtmq_qXC6ZgNOXvL7SQFYg0=.03e4a4e0-885d-466f-991b-02e2e89a31a1@github.com>

On Tue, 7 Feb 2023 23:23:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixe copyright year.

The patch works as expected. NPE problem is resolved. Additionally checked the fix by adding DefaultCaret to component (JTextField) in enabled and disabled states, it works as expected - Blinking caret when enabled and no caret when disabled.

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

Marked as reviewed by honkar (Committer).

PR: https://git.openjdk.org/jdk20/pull/122


From serb at openjdk.org  Wed Feb  8 00:51:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Feb 2023 00:51:43 GMT
Subject: RFR: 8301828: Avoid unnecessary array fill after creation in
 javax.swing.text
In-Reply-To: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
References: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
Message-ID: <5DQQNfzrMb7iwCyroUB1aWuCRoBuyAgen4XJBZbPJ8I=.9380c744-b1fe-4ec6-b444-9540abcd553a@github.com>

On Thu, 26 Jan 2023 20:58:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12235


From serb at openjdk.org  Wed Feb  8 00:52:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Feb 2023 00:52:53 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v3]
In-Reply-To: <Xxe4c_uAxpqTWO1033ocJUfEIS6XlD6Zk6VfPAwb8oE=.e81a4ef3-1f2e-4fc5-93c9-9db8e465ba0e@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <Xxe4c_uAxpqTWO1033ocJUfEIS6XlD6Zk6VfPAwb8oE=.e81a4ef3-1f2e-4fc5-93c9-9db8e465ba0e@github.com>
Message-ID: <KBk77SUO7igvhLLn3BZC08gXDcXDJNZyj90gyCNUiB0=.fea91c94-a0b3-4eb2-b49c-6e51375d8cc8@github.com>

On Mon, 6 Feb 2023 08:46:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test other L&F uninstallDefault

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 76:

> 74: 	    System.out.println("");
> 75: 	    System.out.println("");
> 76:         }

This looks fine, but please fix that "Whitespace error" above.

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

PR: https://git.openjdk.org/jdk/pull/12180


From serb at openjdk.org  Wed Feb  8 01:10:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Feb 2023 01:10:43 GMT
Subject: RFR: 7169951: SwingSet2 throws NullPointerException with Nimbus
 L&F
In-Reply-To: <-Q-JVSsEYumtB6GUFs5SZ6GSWwiujuwNc5kf8XKxa0I=.4abd6cf6-d660-430e-9695-dad66d2da2ea@github.com>
References: <hU2Q5fjkF4qi35_Ai-qPNqxeZx1Xvu6dfKTPuHggbl0=.18f7a248-c577-4f93-9fab-e707289c8dc7@github.com>
 <-Q-JVSsEYumtB6GUFs5SZ6GSWwiujuwNc5kf8XKxa0I=.4abd6cf6-d660-430e-9695-dad66d2da2ea@github.com>
Message-ID: <GqQDS_mSbZFXpqcpsXM87XwwCFhMTfG119awoBxHBzw=.f673d378-0558-4445-827e-0c9a1400394c@github.com>

On Fri, 13 Jan 2023 09:48:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> getStyle().getFont() returns null as "getFontForState(context)" returns null which is because synth state for floating toolbar is invalid which is 0x201 getStyle().getFont()" and "tabPane.getFont()" in normal valid case returns same font which is javax.swing.plaf.FontUIResource[family=SansSerif,name=sansserif,style=plain,size=12]

Where do we set this "invalid" state? Probably it is valid but we do not set the font property for it(or something like that)?

>No regression test is made as it can be verified with SwingSet2..

I am not sure that people will test this usecase if we do not have an instruction to do that nor the tests.

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

PR: https://git.openjdk.org/jdk/pull/11984


From serb at openjdk.org  Wed Feb  8 01:25:47 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Feb 2023 01:25:47 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <0ZbxygIwSrtMb9n4Bm3DI1FpaUi_oNq2LIoVc9NyzFE=.1b52621f-14a5-4eb8-ab2f-c6e3d6954b98@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
 <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
 <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>
 <BmWGzAsMYD3uO8GxInm-9MNHKzOB9Q5yCl269RhqN9I=.a8671024-3f4e-45bd-9f3e-2154d6febeeb@github.com>
 <tj7oXDRuT8PgjJEAHt8bLT8BCRA-S4oeukY
 jgODQLSc=.2d009358-9b1c-4273-bb45-2a71328ec694@github.com>
 <0ZbxygIwSrtMb9n4Bm3DI1FpaUi_oNq2LIoVc9NyzFE=.1b52621f-14a5-4eb8-ab2f-c6e3d6954b98@github.com>
Message-ID: <j37D6mSZl1FHsrod_L3yJUSO7lr3X3UltjvsqTM279c=.7deeb0b3-7df1-4b2e-85e3-da2bd72b9f2d@github.com>

On Fri, 3 Feb 2023 13:07:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The specification isn't clear, and some parts somewhat contradict each other. Logically, the state should transition to DONE as soon as doInBackground completes. Then both done method and listeners are called when the state is DONE that is the background work is complete.

Which parts are contradicts? I mean that the old implementation call DONE-listener last, as specified in the header of the class what part of the spec mention different behavior? Above we discussed that it is possible to see a difference if the listener will do some work on EDT, after the fix the listener will not be called last, is that safe to assume it does not break something?

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Wed Feb  8 01:37:56 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Feb 2023 01:37:56 GMT
Subject: RFR: 8300409: Create an automated regression test for JComboBox
 titled border issues(JDK-8300269)
In-Reply-To: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>
References: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>
Message-ID: <gdPbT_F5Cu_yA5yIynBT3KuK1hGFmBcBZlefIU_1iIg=.021daceb-b93a-4792-a1ba-88f684c0e7df@github.com>

On Wed, 18 Jan 2023 07:41:01 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a automated regression test for JComboBox titled border issues([JDK-8300269](https://bugs.openjdk.org/browse/JDK-8300269)).
> 
> This test passes in JDK-20-ea+15 and fails in JDK-20-ea+16 and above.

If this test will be merged to another PR please close this PR.

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

PR: https://git.openjdk.org/jdk/pull/12061


From mvs at openjdk.org  Wed Feb  8 01:37:57 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 8 Feb 2023 01:37:57 GMT
Subject: RFR: 8300409: Create an automated regression test for JComboBox
 titled border issues(JDK-8300269)
In-Reply-To: <gdPbT_F5Cu_yA5yIynBT3KuK1hGFmBcBZlefIU_1iIg=.021daceb-b93a-4792-a1ba-88f684c0e7df@github.com>
References: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>
 <gdPbT_F5Cu_yA5yIynBT3KuK1hGFmBcBZlefIU_1iIg=.021daceb-b93a-4792-a1ba-88f684c0e7df@github.com>
Message-ID: <8Wqkjj3ObSaCMw9-m0CdyfnNuGygdlfPunQ4WKbn858=.30e45447-2a00-4f4a-a7d9-107f2d8e51c6@github.com>

On Wed, 8 Feb 2023 01:33:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> If this test will be merged to another PR please close this PR.

Yes, I will close this

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

PR: https://git.openjdk.org/jdk/pull/12061


From mvs at openjdk.org  Wed Feb  8 01:37:57 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 8 Feb 2023 01:37:57 GMT
Subject: Withdrawn: 8300409: Create an automated regression test for JComboBox
 titled border issues(JDK-8300269)
In-Reply-To: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>
References: <pixfugLjVG8x0l_8hOAv-TuJSl9RGp5Rc6c7_ungvcs=.bc2069ce-026a-4bd6-980b-77cafd00bb44@github.com>
Message-ID: <S74BNCUDIgLVAGqAUPQm_4grNGueaCLu1OXm5Rji78s=.ac51d6a2-45fe-4f5c-9d03-6b875087c4e5@github.com>

On Wed, 18 Jan 2023 07:41:01 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> Create a automated regression test for JComboBox titled border issues([JDK-8300269](https://bugs.openjdk.org/browse/JDK-8300269)).
> 
> This test passes in JDK-20-ea+15 and fails in JDK-20-ea+16 and above.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12061


From dnguyen at openjdk.org  Wed Feb  8 01:41:43 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 8 Feb 2023 01:41:43 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <NndterQASTmoDb-A5Wj2ZDRfH6GtOaF4SFhAFg21wVM=.c48203de-5abe-4d0e-a000-b9fa6c7b8684@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
 <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>
 <NndterQASTmoDb-A5Wj2ZDRfH6GtOaF4SFhAFg21wVM=.c48203de-5abe-4d0e-a000-b9fa6c7b8684@github.com>
Message-ID: <hj9vlRUZYV8FN6qbc_djvyz8hKeGQ8gdRJDU2lTtie4=.e5fd9f91-8e5a-4404-8235-f3caa950ede2@github.com>

On Tue, 7 Feb 2023 17:02:51 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Also, I think it will be better to make the test automated..something like draw comboBox content into BufferedImage and pixel compare if it is same for disabled/enabled and fail if they are same and iterate for all L&Fs as it will also affect GTK as per the comment

I created an automated test, but for some L&F's (such as Nimbus), an enabled vs disabled ComboBox differs in more than just the text color. The background, border, and button color may change as well. So, even if I shave off the dimensions of the border and button, it seems difficult to detect just the text for comparison.

Before the fix, the issue was that the ComboBox as a whole worked correctly for disabled ComboBoxes with a DLCR, but the text was black instead of grey. This was the only difference.

A manual test might still be the best approach since more aspects than just the test color can be checked. So, I think it's best to not automate this test.

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

PR: https://git.openjdk.org/jdk/pull/12390


From serb at openjdk.org  Wed Feb  8 02:22:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Feb 2023 02:22:43 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v5]
In-Reply-To: <Q1fBhJQZ1g4CrHc4tWDgYOeG5ytqmuKGqdvW3CRVh3o=.d64ff5c3-24d5-4ba8-9cbf-b464cbb559a5@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <6nalpkM3XvpxqLFZ2A_fCLy4EdzwHwYSXMedLUWCOoU=.d403d0c1-6ce5-4776-b9a0-012cff735f8f@github.com>
 <Q1fBhJQZ1g4CrHc4tWDgYOeG5ytqmuKGqdvW3CRVh3o=.d64ff5c3-24d5-4ba8-9cbf-b464cbb559a5@github.com>
Message-ID: <b3km5OdvXPqvMj7al9NosnU8_bYlvHcWPKoh1nF6pNc=.71be0cdf-87f1-4e5c-9229-3ac488bd39d4@github.com>

On Tue, 7 Feb 2023 20:35:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>So it looks all Metal themes use MetalMenuBarUI. As such, moving the registration of MenuBarUI class id from OceanTheme to MetalLookAndFeel makes sense. Especially, taking into account that javadoc for MetalMenuBarUI states, it ?is responsible for the metal look and feel of JMenuBars.?

That class was added when the metal was updated to support the Ocean theme by default. So now it is kind of synonymous metal and ocean. This particular class provides support for the "XXX.gradient" property which is initialized by the Ocean theme or could be set by the application. We can initialize it as suggested but then we should somehow exclude the code path in it for the old "basic/DefaultMetalTheme" which do not use this property(like via MetalLookAndFeel.usingOcean())  The themes you see in the SwingSet2 other than Ocean are all "basic/DefaultMetalTheme" where this class is not used.

> And If I am writing a new Theme do I really have to know which UI classes are always installed ? Its crazy.

No, you do not need to know that. you can subclass the DefaultMetalTheme or OceanTheme, or you can implement the theme from scratch by implementing the abstract MetalTheme. The theme in metal L&F is some kind of color/icons/rendering customization only. But if the new theme will require some custom behavior then yes it will be necessary to set a custom new "MenuBarUI ".

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

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Wed Feb  8 04:03:42 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Feb 2023 04:03:42 GMT
Subject: RFR: 6513512: MetalLookAndFeel.initClassDefaults does not install
 an entry for MetalMenuBarUI [v5]
In-Reply-To: <b3km5OdvXPqvMj7al9NosnU8_bYlvHcWPKoh1nF6pNc=.71be0cdf-87f1-4e5c-9229-3ac488bd39d4@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
 <6nalpkM3XvpxqLFZ2A_fCLy4EdzwHwYSXMedLUWCOoU=.d403d0c1-6ce5-4776-b9a0-012cff735f8f@github.com>
 <Q1fBhJQZ1g4CrHc4tWDgYOeG5ytqmuKGqdvW3CRVh3o=.d64ff5c3-24d5-4ba8-9cbf-b464cbb559a5@github.com>
 <b3km5OdvXPqvMj7al9NosnU8_bYlvHcWPKoh1nF6pNc=.71be0cdf-87f1-4e5c-9229-3ac488bd39d4@github.com>
Message-ID: <M71cudo3uIHpGCA4r5KNQS64gb8qw545P6m9h0syvF4=.57a4fae4-829f-41c4-8a5d-b3a24a707c71@github.com>

On Wed, 8 Feb 2023 02:19:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> We can initialize it as suggested but then we should somehow exclude the code path in it for the old "basic/DefaultMetalTheme" which do not use this property(like via MetalLookAndFeel.usingOcean())

I guess you are talking about this code but it already checks if it is not null and it will be not null only for OceanTheme as other themes dont have this property so will not trace this code path. If new themes do not want, it will not set this property and if they want, then using `MetalLookAndFeel.usingOcean() `will hamper that, I believe, so I think it's fine as it is

https://github.com/openjdk/jdk/blob/2a579ab8392d30a35f044954178c788d16d4b800/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalMenuBarUI.java#L104

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

PR: https://git.openjdk.org/jdk/pull/11646


From jdv at openjdk.org  Wed Feb  8 05:36:42 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 8 Feb 2023 05:36:42 GMT
Subject: RFR: 8272288: Funky multiresolution image breaks graphics context
In-Reply-To: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
References: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
Message-ID: <ufCALqB0uHWHeNhnZZJ0N0kgWQgar2V95E-R1YauNKA=.05809e51-34fe-4fa2-be19-b20627926d8e@github.com>

On Wed, 14 Dec 2022 08:20:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the next iteration of fixing the issue of rendering "broken" image. The fix for [JDK-7183828](https://bugs.openjdk.org/browse/JDK-7183828) changed the possible IllegalArgumentException during rendering to the InvalidPipeException in assumtion that the new exception will be catched by the java2d machinery and the current-accelerated pipeline will be invalidated and software-pipeline will take care about that image.
> 
> But that change uncover another bug, the accelerated-pipeline invalidation by the InvalidPipeException works in D3D pipeline only, other pipelines start to use software based surfaces, but do not report about that the client code, as a result the next code does not work as expected, since contentsLost alwys return false:
> 
>         do {
>             vi.validate(gc);
>             Graphics2D g = vi.createGraphics();
>             g.fillRect(0, 0, vi.getWidth(), vi.getHeight());
>             g.dispose();
>         } while (vi.contentsLost());
> 
> After this change the correct value will be reported by the contentsLost(), so the RepaintManager will be able to catch that.
> But this fix uncovered another bug. That fallback code path in the RepaintManager was not tested on HiDPI screen and does not work well. I'll file a separate bug about that.

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11664


From jdv at openjdk.org  Wed Feb  8 05:36:44 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 8 Feb 2023 05:36:44 GMT
Subject: RFR: 8272288: Funky multiresolution image breaks graphics context
In-Reply-To: <s2GDNJT2Zv0JimXmFG-EtF3alWT-K16tyVwHIGjuSbI=.21e9832b-b662-41c2-acbd-34480aa4f03d@github.com>
References: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
 <W_nWnq9ale7jiakx-FbMzSwAcjTAW1Ymgw9ITT-nnRc=.1071a41b-39dd-40d2-b4f1-7da5a84f7a14@github.com>
 <s2GDNJT2Zv0JimXmFG-EtF3alWT-K16tyVwHIGjuSbI=.21e9832b-b662-41c2-acbd-34480aa4f03d@github.com>
Message-ID: <1-aNfyofl1faGWnZqb-FiG9xurVfL00Jfon9IfzLOew=.e21de6bf-9127-436a-8e97-2279a3c0b9c2@github.com>

On Mon, 6 Feb 2023 22:01:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/java/awt/image/VolatileImage/ReportRenderingError.java line 91:
>> 
>>> 89:             Graphics2D g = vi.createGraphics();
>>> 90:             g.setColor(Color.RED);
>>> 91:             g.drawImage(image, 0, 0, null); // <- can cause InvalidPipeException
>> 
>> This drawImage call is expected to through InvalidPipeException all the times or is it intermittent?
>> If it is intermittent why so? Please explain.
>> 
>> It looks like after https://github.com/openjdk/jdk/commit/8da6c8d6 we will through InvalidPipeException for all cases of custom images and not intermittently.
>
> It is not really intermittent but depends on the java2d pipeline currently in use. InvalidPipeException is produced by the accelerated pipelines but code works fine on GDI for example.

Thanks for the clarification

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

PR: https://git.openjdk.org/jdk/pull/11664


From psadhukhan at openjdk.org  Wed Feb  8 05:36:55 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Feb 2023 05:36:55 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v4]
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

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

  jcheck fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12180/files
  - new: https://git.openjdk.org/jdk/pull/12180/files/3f6f018e..cd4cb65a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Wed Feb  8 05:48:47 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Feb 2023 05:48:47 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v13]
In-Reply-To: <QsSZCEUWZ4oAi4u7p1g2gM_FVg1UK55IHT1cw6DATzY=.40a01aa3-f4d2-454b-96e2-56e92ac06a52@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <OZNhKFK-aQRDBye3AE_6SqkeC_edGS0rTn_GyyqM5Ug=.117e492d-bb7e-40f4-ac7e-c99861975677@github.com>
 <QsSZCEUWZ4oAi4u7p1g2gM_FVg1UK55IHT1cw6DATzY=.40a01aa3-f4d2-454b-96e2-56e92ac06a52@github.com>
Message-ID: <G35-M5X7jh24nv-olEAPHwBQEgQ6c_YpVhHrSXDuB44=.6edbead1-e15e-415e-9e76-a35c34cb94d8@github.com>

On Tue, 7 Feb 2023 17:16:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Since a CSR is required, I suggest updating the spec for `isDone` method so that it returns `true` only after `doInBackground` exits. Now `isDone` returns `true` after `cancel` completes but the `DONE` state isn't reached yet.

My take is current code fix and spec clarification is done to make code/spec wording consistent with **existing** spec
whereas this change is to **enhance** the code/spec which I think we should keep it separate from this fix, as this will cause JCK test to be excluded and will cause JCK to update the test and I am not sure how that will pan out, so I suggest to keep the change to minimal to the extent only which is needed for this fix..

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Wed Feb  8 06:36:43 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Feb 2023 06:36:43 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v5]
In-Reply-To: <-owWLhz4rfTDxRWUPkzPSTwOog6of3OiEIFSbdiSrgM=.4a953820-b264-405e-be03-0bed8fce70e3@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <-owWLhz4rfTDxRWUPkzPSTwOog6of3OiEIFSbdiSrgM=.4a953820-b264-405e-be03-0bed8fce70e3@github.com>
Message-ID: <BNIwaUoZeA5UHAI3ufXc2eg_MutxZpnJh1R9TUuBA00=.73441346-36ec-4ec0-9ab5-6a7273a17ace@github.com>

On Tue, 7 Feb 2023 23:14:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update years. Add conditional

`SynthComboBoxUI.createRenderer` points to `SynthComboBoxRenderer `so I think `DefaultListCellRenderer `should not come into picture for rendering cells in the list which should go via `getListCellRendererComponent`.
If it is playing a part, then how it works in other L&F which also has it own renderer (for example, `BasicComboBoxUI.createRenderer` points to `BasicComboBoxRenderer`, AquaComboBox points to `AquaComboBoxRenderer`) and they dont have this listener to make it work, so the question why do we need a listener for Synth still not clear to me..

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

PR: https://git.openjdk.org/jdk/pull/12390


From psadhukhan at openjdk.org  Wed Feb  8 06:36:45 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Feb 2023 06:36:45 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <hj9vlRUZYV8FN6qbc_djvyz8hKeGQ8gdRJDU2lTtie4=.e5fd9f91-8e5a-4404-8235-f3caa950ede2@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
 <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>
 <NndterQASTmoDb-A5Wj2ZDRfH6GtOaF4SFhAFg21wVM=.c48203de-5abe-4d0e-a000-b9fa6c7b8684@github.com>
 <hj9vlRUZYV8FN6qbc_djvyz8hKeGQ8gdRJDU2lTtie4=.e5fd9f91-8e5a-4404-8235-f3caa950ede2@github.com>
Message-ID: <CgpsraezLr8k2n9_8eFpNfeYusF-zd2QjyhUkQZFOx0=.cd471c4c-a8f3-437c-9ffc-255d4147a649@github.com>

On Wed, 8 Feb 2023 01:39:04 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> I created an automated test, but for some L&F's (such as Nimbus), an enabled vs disabled ComboBox differs in more than just the text color. The background, border, and button color may change as well

Then can we not compare the comboBox without DLCR with comboBox with DLCR when both are disabled...both should be same as per your screenshot

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

PR: https://git.openjdk.org/jdk/pull/12390


From duke at openjdk.org  Wed Feb  8 06:36:54 2023
From: duke at openjdk.org (duke)
Date: Wed, 8 Feb 2023 06:36:54 GMT
Subject: Withdrawn: 8298352: apple.laf.JRSUIUtils class creates many
 indirections
In-Reply-To: <p7LTlpangyiscxAO3M7u4VVNNqFnOo8f8m1ZU62YyGw=.75a40977-d36d-46cb-a564-a28ffda89e0a@github.com>
References: <p7LTlpangyiscxAO3M7u4VVNNqFnOo8f8m1ZU62YyGw=.75a40977-d36d-46cb-a564-a28ffda89e0a@github.com>
Message-ID: <bX5VCJAcgt-2tM7vJbkQ0fv30VpjyifYdD4VswO5Ozk=.01c25d69-7696-43a6-b128-8b24267bc457@github.com>

On Sun, 18 Sep 2022 21:23:12 GMT, SWinxy <duke at openjdk.org> wrote:

> `JRSUIUtils.java` structurally does things weirdly. The utility class mostly passes parameters from functions to other functions. The indirection makes things harder to understand the eventual purpose.
> 
> Take `AquaInternalFrameBorderMetrics.java`. It has a `static boolean` that caches a call to `shouldUseLegacyBorderMetrics()`, which returns `isSnowLeopardOrBelow`, itself a cached call to `isMacOSXSnowLeopardOrBelow()`, which is what finally calls `currentMacOSXVersionMatchesGivenVersionRange()`. When looking at the code, it takes time to unravel the path it takes. Instead of that, a `public static final boolean` can expose the cached value and, in doing so, exposes the *meaning* behind the check.
> 
> In `AquaLookAndFeel.java`, the value of `TabbedPaneUI` is calculated using `JRSUIUtils.TabbedPane.shouldUseTabbedPaneContrastUI()`, but that could mean any reason for why `"AquaTabbedPaneContrastUI"` may be the value as opposed to `"AquaTabbedPaneUI"`. Replacing it with `JRSUIUtils.isSnowLeopardOrBelow` reveals that it actually has to do with the OS version being, well, Snow Leopard or below.
> 
> These change makes understanding the code easier and quicker. Also more optimized.
> 
> Changes:
> * add JRSUIConstants.ScrollBarPart.ordinal() to return the property's ordinal value, which is not public
> * change 3 access modifiers in JRSUIControl to public allowing for access outside the package
> * JRSUIConstants.NineSliceMetricsProvider changed to a normal Function<>
> * cache `isMacOSXBigSurOrAbove` rather than calling it twice
> * inline the functions for clarity
> * change static initialization to group all version checks together
> * document JRSUIUtils

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10326


From jwaters at openjdk.org  Wed Feb  8 08:31:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 08:31:09 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v6]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <HkL5vx2E1jDr55u_pnt2FZtVMb5knZ4SnroOytx9h28=.998951f9-ed1a-4408-b591-44e7c507ceb7@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

  Revert awt_List.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/e6d54f21..cb0f33bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=04-05

  Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

PR: https://git.openjdk.org/jdk/pull/12305


From jwaters at openjdk.org  Wed Feb  8 08:31:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 08:31:11 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
 <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
 <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>
Message-ID: <oismWdH6blxn1BU_dld0qAgmiB_5O_EeXvNGlWMD7_8=.f2492f68-bf96-4704-a39b-dd2da351eb10@github.com>

On Tue, 7 Feb 2023 19:19:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994
>
>> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994
> 
> Thank you, @TheShermanTanker.
> 
> Do you still want to keep the changes?
> If it's not too critical, I would rather prefer you revert the changes to `awt_List.cpp`.

No worries, I'm fine with reverting `awt_List.cpp`, I can set my local branch up to avoid a rebase conflict when the commented code does get deleted rather easily

On the other hand, could I trouble you for a quick review of https://github.com/openjdk/jdk/pull/12405? It's just a constructor from libawt that I happened to overlook in my previous Pull Request on initialization orders. Sorry for the trouble!

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

PR: https://git.openjdk.org/jdk/pull/12305


From jwaters at openjdk.org  Wed Feb  8 08:34:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 08:34:05 GMT
Subject: RFR: 8301756: Missed constructor from 8301659 [v3]
In-Reply-To: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
References: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
Message-ID: <3T_3LrzxlbBYuso6tCq0NpvWUD5KGOfDENuTD2vTF7c=.edb77937-2d03-432b-aa63-3601cbc59ad0@github.com>

> 8301659 has missed a reordered constructor defined inside libawt

Julian Waters 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 patch-5
 - Merge branch 'openjdk:master' into patch-5
 - Reorder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12405/files
  - new: https://git.openjdk.org/jdk/pull/12405/files/aae07b9e..cb3dbe97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12405&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12405&range=01-02

  Stats: 3193 lines in 143 files changed: 2763 ins; 138 del; 292 mod
  Patch: https://git.openjdk.org/jdk/pull/12405.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12405/head:pull/12405

PR: https://git.openjdk.org/jdk/pull/12405


From jwaters at openjdk.org  Wed Feb  8 08:36:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 08:36:03 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v7]
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <6R_itk-rGsyjqyl0jNSC9LfGx9LC9cgFVBEy5oQAgYU=.90078df9-9a42-4ece-b334-e801a2129aef@github.com>

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

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

 - Merge branch 'openjdk:master' into comments
 - Revert awt_List.cpp
 - D3DVertexCacher.cpp
 - awt_List.cpp
 - sspi.cpp
 - awt_Toolkit.cpp
 - Merge branch 'openjdk:master' into comments
 - Partial Revert
 - sspi.cpp
 - Comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12305/files
  - new: https://git.openjdk.org/jdk/pull/12305/files/cb0f33bf..85a999e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12305&range=05-06

  Stats: 7867 lines in 252 files changed: 6097 ins; 1034 del; 736 mod
  Patch: https://git.openjdk.org/jdk/pull/12305.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12305/head:pull/12305

PR: https://git.openjdk.org/jdk/pull/12305


From aivanov at openjdk.org  Wed Feb  8 09:00:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 09:00:54 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v5]
In-Reply-To: <MlEUPB2T45M5xgVlYahStFtJX-iZV2hW2z_RJUnJdwE=.93193e6e-0444-4517-a4fc-edb4e6c6f8e1@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
 <MlEUPB2T45M5xgVlYahStFtJX-iZV2hW2z_RJUnJdwE=.93193e6e-0444-4517-a4fc-edb4e6c6f8e1@github.com>
Message-ID: <CQGpXfAL0p_RX3jFd4qCvLgvdVh5bTxso7W2NeRmF30=.30dddccc-f4df-4ed8-94eb-8a9eb096d5f1@github.com>

On Tue, 7 Feb 2023 21:57:16 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
>> 
>> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.
>
> 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 12 additional commits since the last revision:
> 
>  - minor review changes
>  - Merge branch 'master' into MetalBorderRefactor_8294484
>  - review changes: AbstractMetalWindowBorder, strokeWidth rename
>  - Merge branch 'master' into MetalBorderRefactor_8294484
>  - minor change
>  - removed unused import
>  - added updateColor(), isActive() to MetalBorder
>  - test summary changes
>  - deleted InternalFrameBorderTest
>  - moved corner var to AbstractMetalBorder
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/0546dac6...e9b37edc

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12391


From aivanov at openjdk.org  Wed Feb  8 09:10:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 09:10:44 GMT
Subject: RFR: 8301756: Missed constructor from 8301659 [v3]
In-Reply-To: <3T_3LrzxlbBYuso6tCq0NpvWUD5KGOfDENuTD2vTF7c=.edb77937-2d03-432b-aa63-3601cbc59ad0@github.com>
References: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
 <3T_3LrzxlbBYuso6tCq0NpvWUD5KGOfDENuTD2vTF7c=.edb77937-2d03-432b-aa63-3601cbc59ad0@github.com>
Message-ID: <6vIVChnc5uOl4PkjK7FZWy9Xa_xtg3S3pmjDkfvbTO0=.fa99af51-b0a8-41f9-9293-35ef07842c43@github.com>

On Wed, 8 Feb 2023 08:34:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8301659 has missed a reordered constructor defined inside libawt
>
> Julian Waters 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 patch-5
>  - Merge branch 'openjdk:master' into patch-5
>  - Reorder

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12405


From jwaters at openjdk.org  Wed Feb  8 09:10:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 09:10:46 GMT
Subject: RFR: 8301756: Missed constructor from 8301659 [v3]
In-Reply-To: <3T_3LrzxlbBYuso6tCq0NpvWUD5KGOfDENuTD2vTF7c=.edb77937-2d03-432b-aa63-3601cbc59ad0@github.com>
References: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
 <3T_3LrzxlbBYuso6tCq0NpvWUD5KGOfDENuTD2vTF7c=.edb77937-2d03-432b-aa63-3601cbc59ad0@github.com>
Message-ID: <3hOi-L0aH1HrgxJYfaryvroIfHIiCw6Pq-zfEKZLZAo=.ce32f8f1-aa4d-4848-a3f9-4f90a904363e@github.com>

On Wed, 8 Feb 2023 08:34:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> 8301659 has missed a reordered constructor defined inside libawt
>
> Julian Waters 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 patch-5
>  - Merge branch 'openjdk:master' into patch-5
>  - Reorder

Thanks aivanov!

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

PR: https://git.openjdk.org/jdk/pull/12405


From jwaters at openjdk.org  Wed Feb  8 09:13:55 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 09:13:55 GMT
Subject: Integrated: 8301756: Missed constructor from 8301659
In-Reply-To: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
References: <qi-mntF-c6ACky0PGK5UV_zuLev_ktwsuc4GYxdy6bw=.2c558f0a-9690-4b7b-866f-924a2eedd69f@github.com>
Message-ID: <40PdHRIS3FGvumxU6uhA4OqDv-OJjWkOfTYtM6XErTM=.1ff5f636-d990-4f13-a925-2aadc61acc15@github.com>

On Fri, 3 Feb 2023 09:54:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> 8301659 has missed a reordered constructor defined inside libawt

This pull request has now been integrated.

Changeset: 0f08785c
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f08785c01226961fb6040d5d30917308de34a88
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8301756: Missed constructor from 8301659

Reviewed-by: aivanov

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

PR: https://git.openjdk.org/jdk/pull/12405


From aivanov at openjdk.org  Wed Feb  8 09:29:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 09:29:55 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v2]
In-Reply-To: <f1sAemrQOD77uss-O673HGruBlWt2Adu9lmq2CLQiWI=.d54d270f-ede5-461c-9744-96c8a345ff9e@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <_F66GasxdremocPjHV9uOyJLZQy83LD3KZ7FJFgtPU4=.f8e837d5-8ebc-4f10-8849-47334cb213d9@github.com>
 <_ghd81JZBoqpumCfJYCRJBx2If1fVThQ3Djv7l4NSjg=.e73fdc48-6100-4a73-8cb2-8fe2df6c0d40@github.com>
 <-S1P8rII2nr7IZWPLVrIRSbmcTdBujDX_5eto_GUUxM=.a2b606ae-8dd9-4942-8f92-b536a8154ff6@github.com>
 <f1sAemrQOD77uss-O673HGruBlWt2Adu9lmq2CLQiWI=.d54d270f-ede5-461c-9744-96c8a345ff9e@github.com>
Message-ID: <xLG-eNR0dJNuu2q0DzxStR4UBNMeCYaKm5GsyNWa-gg=.17ffbcac-255a-40b5-83c1-5714b6174ef6@github.com>

On Fri, 3 Feb 2023 22:39:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The suggested change does fix the mouse pointer issue.
> 
> However, the test still fails for me:
> 
> ```
> Exception in thread "main" java.lang.RuntimeException: Robot.getPixelColor test failed on Screen #1!
> 	at MultiScreenLocationTest.main(MultiScreenLocationTest.java:98)
> ```
> 
> Is it possible to add diagnostic information?
> 
> If `moveMove` fails, one may want to see what the coordinates are, what the expected coordinates are and what the bounds of the current screen are.
> 
> If `getPixelColor` fails, what is the color of the pixel and what is the expected color?
> 
> These changes will be helpful for you while you debugging and updating the test as well as for anyone who has to deal with the test later.

It does, indeed. It's required.

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

PR: https://git.openjdk.org/jdk/pull/10363


From aivanov at openjdk.org  Wed Feb  8 09:30:00 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 09:30:00 GMT
Subject: RFR: 8292588: [macos]
 Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java:
 Robot.mouseMove test failed on Screen #0 [v5]
In-Reply-To: <2VwBZ7updndz-IQpRPzIMbCtigNqjiYR30iZX2REcWg=.ad216634-0a88-467e-9a78-bf7c87ed1c32@github.com>
References: <R3VxHUfsUYcrvLTHrJJntWKXdwoqVvmc-wIWALKmL3g=.67d213c6-2add-4b60-a931-7578157e8ffe@github.com>
 <2VwBZ7updndz-IQpRPzIMbCtigNqjiYR30iZX2REcWg=.ad216634-0a88-467e-9a78-bf7c87ed1c32@github.com>
Message-ID: <HxMNgtuB0kGsFv-1H4gmPhv3r1muil-HjFYJwP_7DK8=.5e50e43d-907c-4013-a652-1bc8963485f6@github.com>

On Fri, 3 Feb 2023 20:24:16 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Fixed test bug where mouse location was being calculated before robot mouseMove operation was complete
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   uncommented portion of test

test/jdk/java/awt/Multiscreen/MultiScreenLocationTest/MultiScreenLocationTest.java line 115:

> 113:                             String.format("0x%08X",image.getRGB(image.getWidth() - 1, image.getHeight() - 1)));
> 114:                     System.out.println("Robot.createScreenCapture Top Left Actual: " +
> 115:                             String.format("0x%08X",image.getRGB(0, image.getHeight() - 1)));

There's no space after the comma, after the format string. Yet there are spaces in `getRGB`, probably because they're copied from the `if`-condition.

test/jdk/java/awt/regtesthelpers/Util.java line 178:

> 176:             }
> 177:             System.out.println("Robot.getPixelColor Expected: " + color);
> 178:             System.out.println("Robot.getPixelColor Actual: " + screen);

This may be not the best solution. If the method is used on a large image / rectangle (it's called from `testBoundsColor`), the output could be flooded with messages. Eventually, it may slow down test execution. At the same time, there's no other way to provide debugging info.

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

PR: https://git.openjdk.org/jdk/pull/10363


From aivanov at openjdk.org  Wed Feb  8 09:36:45 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 09:36:45 GMT
Subject: RFR: 8300549: JFileChooser Approve button tooltip is null in Aqua
 L&F in CUSTOM_DIALOG mode [v2]
In-Reply-To: <VIAJ0-tM7BIjE5c-8vG8IfDOnMKZ-IWuExfyZPIizj4=.31771e62-e83d-4daa-a964-a55a9a1b4838@github.com>
References: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
 <VIAJ0-tM7BIjE5c-8vG8IfDOnMKZ-IWuExfyZPIizj4=.31771e62-e83d-4daa-a964-a55a9a1b4838@github.com>
Message-ID: <C8gb-jpJ3dNVfj-M-PhMIWGmKhnvUFfsvoW70Qty01s=.13bf8ab5-adb8-4dd1-9f37-bea38cedf6aa@github.com>

On Mon, 30 Jan 2023 15:05:55 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _JFilechooser_ returns _null_ for Approve button tool tip in `CUSTOM_DIALOG` mode (`getToolTipText()`). The fallback text has been set to "Choose" text. Observation found in validating the test of PR - #11901.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Property added

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12198


From aivanov at openjdk.org  Wed Feb  8 09:41:43 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 09:41:43 GMT
Subject: RFR: 8301567: The
 test/jdk/java/awt/AppContext/ApplicationThreadsStop/java.policy is unused
In-Reply-To: <86QBcu6i526TV5xFNw3VO51kwBQAWHSAB637SIT2kxI=.3b3861d3-093f-45bc-aee8-edaa38208359@github.com>
References: <86QBcu6i526TV5xFNw3VO51kwBQAWHSAB637SIT2kxI=.3b3861d3-093f-45bc-aee8-edaa38208359@github.com>
Message-ID: <X2FzudXOw4zuyDthPjW6bohMqLnmabehW-oXG_RpZ4g=.bb43b3b8-ad6f-4b10-ad28-201b364843de@github.com>

On Wed, 1 Feb 2023 00:54:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test ApplicationThreadsStop.java was removed by the [JDK-8289616](https://bugs.openjdk.org/browse/JDK-8289616) but the related java.policy was not deleted.

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12356


From psadhukhan at openjdk.org  Wed Feb  8 09:46:21 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Feb 2023 09:46:21 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v14]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <PwPlV_SYqbhZ4gFkXgLfQi7HZeJVYsPvuWcsiWMeeGg=.3711aca0-106a-4409-9292-04cc2bf579eb@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Test updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/7f7bda7c..c5892188

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=12-13

  Stats: 15 lines in 1 file changed: 9 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Wed Feb  8 10:17:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 10:17:48 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v5]
In-Reply-To: <9isfpPmDbm6x0J3OiEypPfSYS7UKhmHY1IVig8FWdq8=.3ca9af78-6ee2-4374-a593-4cebc2a2d8c3@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
 <9isfpPmDbm6x0J3OiEypPfSYS7UKhmHY1IVig8FWdq8=.3ca9af78-6ee2-4374-a593-4cebc2a2d8c3@github.com>
Message-ID: <qHsm2AbdHYDjEhVY9urw4df0M1sBM9YuPMy102fxYMM=.fcc30b34-97b1-4617-b0c0-1079956605a5@github.com>

On Mon, 6 Feb 2023 10:14:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
>> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
>> 
>> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
>> 
>> No regression test is added as it can be verified by SwingSet2 Tabledemo..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ignore set horiz/vert lines if showGrid is true by default

You should save the old values and always set the new value. In uninstall, you should restore the previous values.

For what it's worth, each Look and Feel must do it, otherwise there are other combinations of L&Fs where the property isn't restored.

The default value for `showHorizontalLines` and `showVerticalLines` is `false`. So it's changed by a L&F and is not restored.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 189:

> 187:             if (!showGrid) {
> 188:                 table.setShowGrid(false);
> 189:             }

What if the grid isn't displayed and `showGrid` is set to `true`? Then the value of `showGrid` isn't respected again.

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 242:

> 240:                 table.setShowVerticalLines(true);
> 241:             }
> 242:         }

It should always restore the previous values.

test/jdk/javax/swing/JTable/TestJTableGridReset.java line 65:

> 63:                 table.setShowVerticalLines(true);
> 64:             });
> 65:             SwingUtilities.updateComponentTreeUI(table);

I'm pretty sure this method must also be called on EDT as it changes the state of Swing components.

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12385


From aivanov at openjdk.org  Wed Feb  8 11:39:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 11:39:49 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v4]
In-Reply-To: <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>
Message-ID: <PNSQ-wKEc7pgkis5glTEc-Wz2UADaKSDAS6cLSTg6BM=.1604b1ab-a68d-4ade-b707-e97145fdbc35@github.com>

On Wed, 8 Feb 2023 05:36:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck fix

> Synth `installDefaults` methods set the font, but its inverse methods `uninstallDefaults` do not remove them.

It's a common problem in L&F code, see [JDK-8278620](https://bugs.openjdk.org/browse/JDK-8278620) and #10565. However, that changeset led to test failures which are still under investigation.

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Wed Feb  8 11:43:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 11:43:44 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v4]
In-Reply-To: <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>
Message-ID: <KwOqsnM3uALhU-QA-Ypw-v54KRf9ef2sHkG89_qiSqE=.05400b65-efcc-4daf-b6fa-3df42959220b@github.com>

On Wed, 8 Feb 2023 05:36:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck fix

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 28:

> 26:  * @summary  Verifies if JFileChooser font reset after Look & Feel change
> 27:  * @run main JFileChooserFontReset
> 28:  */

May I ask you to move the jtreg tags to the class declaration? This way they're visible when you open the file in the IDE.

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Wed Feb  8 11:47:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 11:47:46 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v4]
In-Reply-To: <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>
Message-ID: <BvvaVj_ywvQdL4G5gXeTWfw33niTKV1mIpxEjSS1sPk=.f2190474-b5f2-4084-b78f-528541bc0eb0@github.com>

On Wed, 8 Feb 2023 05:36:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jcheck fix

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 53:

> 51:             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));
> 52:             JFileChooser fc = new JFileChooser();
> 53:             Font origFont = fc.getFont();

This is really inconsistent: you set L&F on EDT but you create `JFileChooser` on main thread. You should either do everything on main thread or, preferably, move all the test code onto EDT.

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

PR: https://git.openjdk.org/jdk/pull/12180


From jwaters at openjdk.org  Wed Feb  8 14:27:44 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 8 Feb 2023 14:27:44 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v5]
In-Reply-To: <oismWdH6blxn1BU_dld0qAgmiB_5O_EeXvNGlWMD7_8=.f2492f68-bf96-4704-a39b-dd2da351eb10@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <depwU23Dzv4nOVeZpwBhSEUjgn3ZwWTtdYLmCPasyUA=.a334896b-d547-45ef-94b0-cef0c62b045a@github.com>
 <PQIF0R8tSP8FsiWWLhrtcZS9NyPQhABKls8pCkcKlzg=.c62724f8-00a2-48eb-a6a9-b2c89f4255af@github.com>
 <OBbus329e_rBXDDvoDcYmfquaprHAVJy5ihp7Huka10=.67135053-7c22-427f-a17a-f01db8590356@github.com>
 <5aSyOoHJqRuzH5A16v1UmrYZa0hjvn6fr79TxwrtLzc=.564172fd-5d66-4865-ac42-9ee3b055e50b@github.com>
 <6sL1l3UV4gda4V6L8yt3IWKoPsKCl0hW7sTdS5cHZRI=.809b270f-03d5-4293-ab84-1afea0483331@github.com>
 <M057E8l6VmkeipeDlOpNU2FktKOVBsuJQ3PVIDSRCcU=.dbdc49de-787d-46db-9714-79371547b84a@github.com>
 <oismWdH6blxn1BU_dld0qAgmiB_5O_EeXvNGlWMD7_8=.f2492f68-bf96-4704-a39b-dd2da351eb10@github.com>
Message-ID: <K3Vr5qyrS2-oC33pobb4o4VpY0veF-bpqkZ7zVXh90M=.c2d09121-af20-40f3-b6e0-b7c402af1a2a@github.com>

On Wed, 8 Feb 2023 08:23:59 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>>> Alright here you go :) https://bugs.openjdk.org/browse/JDK-8301994
>> 
>> Thank you, @TheShermanTanker.
>> 
>> Do you still want to keep the changes?
>> If it's not too critical, I would rather prefer you revert the changes to `awt_List.cpp`.
>
> No worries, I'm fine with reverting `awt_List.cpp`, I can set my local branch up to avoid a rebase conflict when the commented code does get deleted rather easily
> 
> On the other hand, could I trouble you for a quick review of https://github.com/openjdk/jdk/pull/12405? It's just a constructor from libawt that I happened to overlook in my previous Pull Request on initialization orders. Sorry for the trouble!

Thanks for the review! Are the other changes here ok with you in the meantime?

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

PR: https://git.openjdk.org/jdk/pull/12305


From aturbanov at openjdk.org  Wed Feb  8 14:32:59 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 8 Feb 2023 14:32:59 GMT
Subject: Integrated: 8301828: Avoid unnecessary array fill after creation in
 javax.swing.text
In-Reply-To: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
References: <bmOqmiLTTDEg-rSaznJdXSBwF35yfy7Ki0NjkZYuZag=.930665b9-3021-408f-9a9b-107b582502f5@github.com>
Message-ID: <pf4diPKuIkPjzmjoI1K2tO8Y-Hs_rqg2kHEquON4a6U=.31c5d435-0ac2-4dcb-b369-28b8be6759ce@github.com>

On Thu, 26 Jan 2023 20:58:45 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> No need to fill elements of array with default values if it was just created. Java guarantees that all elements of numeric array have default values after allocations - 0.

This pull request has now been integrated.

Changeset: 9af2ea20
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9af2ea203db8b2f3da224bf0582411a9a9855c02
Stats:     7 lines in 2 files changed: 0 ins; 5 del; 2 mod

8301828: Avoid unnecessary array fill after creation in javax.swing.text

Reviewed-by: prr, serb

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

PR: https://git.openjdk.org/jdk/pull/12235


From prr at openjdk.org  Wed Feb  8 17:05:50 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 17:05:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <k936iKtvEA2hePHELvYlZyuhxywnnYnPiGC7a54J0AQ=.b72ff6c6-dd09-4a21-8926-880641e8620c@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>
 <k936iKtvEA2hePHELvYlZyuhxywnnYnPiGC7a54J0AQ=.b72ff6c6-dd09-4a21-8926-880641e8620c@github.com>
Message-ID: <-t6p4heuqGQwq2t_l-vKwFvGM_qz92H3PdwW4tKJpg0=.2d877e71-9a62-4f6b-84c3-74c49f1c8727@github.com>

On Tue, 7 Feb 2023 23:16:14 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 1054:
>> 
>>> 1052:         if (rate != 0) {
>>> 1053:             if (component != null && component.isEditable()) {
>>> 1054:                 if (flasher == null) {
>> 
>> So later if there is a non-editable component, what happens ?
>> Some existing logic for that will kick in ?
>
> Yes, when the the caret is to be assigned to a component it will reset the blink rate and the logic will kick in. Manually tested with the possible scenarios like adding custom set blink rate cursor to a non-editable component and then turn it into editable later, add to editable and switch to non-editable later and so on.

So if I go back and look at the code before your previous fix, there was no check,
so the timer is created and then I'd expect applies when the caret is installed on a component.
Here that behaviour is changed, so that if we create a caret, then call setBlinkRate(), and then install()
then the blink rate appears to be ignored whereas before 4512626 it was applied.

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 18:15:56 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 18:15:56 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <-t6p4heuqGQwq2t_l-vKwFvGM_qz92H3PdwW4tKJpg0=.2d877e71-9a62-4f6b-84c3-74c49f1c8727@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>
 <k936iKtvEA2hePHELvYlZyuhxywnnYnPiGC7a54J0AQ=.b72ff6c6-dd09-4a21-8926-880641e8620c@github.com>
 <-t6p4heuqGQwq2t_l-vKwFvGM_qz92H3PdwW4tKJpg0=.2d877e71-9a62-4f6b-84c3-74c49f1c8727@github.com>
Message-ID: <txXotmyt5U_uhRQ38175kf8Jn42iKKxmfwF6shhMASo=.2fbf94f0-5b27-4670-9b59-a014e250488b@github.com>

On Wed, 8 Feb 2023 17:03:01 GMT, Phil Race <prr at openjdk.org> wrote:

> if we create a caret, then call setBlinkRate(), and then install()
> then the blink rate appears to be ignored whereas before 4512626 it was applied.

Ok, if the text component is already visible and editable and focused and we install the new caret then the blink rate will not have an effect until the focus is lost and regained or until it became non-editable - and i think that was close to what we had before and there is a bug to investigate and optimize such corner case. In all other cases the code works fine. The value set is being preserved and will be reactivated when any of the methods such as focusGained or when the component installUI is called - if the cursor is set before component becomes visible - will cause to re-evaluate the blink rate and the stored value set by user will take place.

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

PR: https://git.openjdk.org/jdk20/pull/122


From serb at openjdk.org  Wed Feb  8 19:59:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Feb 2023 19:59:53 GMT
Subject: Integrated: 8301567: The
 test/jdk/java/awt/AppContext/ApplicationThreadsStop/java.policy is unused
In-Reply-To: <86QBcu6i526TV5xFNw3VO51kwBQAWHSAB637SIT2kxI=.3b3861d3-093f-45bc-aee8-edaa38208359@github.com>
References: <86QBcu6i526TV5xFNw3VO51kwBQAWHSAB637SIT2kxI=.3b3861d3-093f-45bc-aee8-edaa38208359@github.com>
Message-ID: <S6vBJj2a2PBt16yeRomrFSe69XmZH5gzfEmWZ8pDVTw=.e4c9b9e9-6ab9-4753-9591-325d861f1c58@github.com>

On Wed, 1 Feb 2023 00:54:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The test ApplicationThreadsStop.java was removed by the [JDK-8289616](https://bugs.openjdk.org/browse/JDK-8289616) but the related java.policy was not deleted.

This pull request has now been integrated.

Changeset: 631a2790
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/631a2790e5d5b3eac5102dbc42e57feb94bfc23d
Stats:     5 lines in 1 file changed: 0 ins; 5 del; 0 mod

8301567: The test/jdk/java/awt/AppContext/ApplicationThreadsStop/java.policy is unused

Reviewed-by: aivanov

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

PR: https://git.openjdk.org/jdk/pull/12356


From prr at openjdk.org  Wed Feb  8 20:15:50 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 20:15:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <txXotmyt5U_uhRQ38175kf8Jn42iKKxmfwF6shhMASo=.2fbf94f0-5b27-4670-9b59-a014e250488b@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>
 <k936iKtvEA2hePHELvYlZyuhxywnnYnPiGC7a54J0AQ=.b72ff6c6-dd09-4a21-8926-880641e8620c@github.com>
 <-t6p4heuqGQwq2t_l-vKwFvGM_qz92H3PdwW4tKJpg0=.2d877e71-9a62-4f6b-84c3-74c49f1c8727@github.com>
 <txXotmyt5U_uhRQ38175kf8Jn42iKKxmfwF6shhMASo=.2fbf94f0-5b27-4670-9b59-a014e250488b@github.com>
Message-ID: <GjEoc7gDBiOqf5772h5yTCgDEdYXM7JFRNMWSB1onHY=.878ba844-5200-4109-b939-63fdd3becd3e@github.com>

On Wed, 8 Feb 2023 18:12:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> So if I go back and look at the code before your previous fix, there was no check,
>> so the timer is created and then I'd expect applies when the caret is installed on a component.
>> Here that behaviour is changed, so that if we create a caret, then call setBlinkRate(), and then install()
>> then the blink rate appears to be ignored whereas before 4512626 it was applied.
>
>> if we create a caret, then call setBlinkRate(), and then install()
>> then the blink rate appears to be ignored whereas before 4512626 it was applied.
> 
> Ok, if the text component is already visible and editable and focused and we install the new caret then the blink rate will not have an effect until the focus is lost and regained or until it became non-editable - and i think that was close to what we had before and there is a bug to investigate and optimize such corner case. In all other cases the code works fine. The value set is being preserved and will be reactivated when any of the methods such as focusGained or when the component installUI is called - if the cursor is set before component becomes visible - will cause to re-evaluate the blink rate and the stored value set by user will take place.

Suppose I have this code

Caret c = new DefaultCaret()
c.setBlinkRate(50);
c.install(editableJComponent);

BEFORE 4512626 the JDK code looked like this

     if (rate != 0) {
            if (flasher == null) {
                flasher = new Timer(rate, handler);
            }
            flasher.setDelay(rate);
        }


With your fix it looks like this

     if (rate != 0) {
            if (component != null && component.isEditable()) {
               if (flasher == null) {
                   flasher = new Timer(rate, handler);
               }
             }
        }


So with my sample application code there's a change that my blink rate is completely lost.

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

PR: https://git.openjdk.org/jdk20/pull/122


From achung at openjdk.org  Wed Feb  8 20:55:44 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 8 Feb 2023 20:55:44 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v5]
In-Reply-To: <-owWLhz4rfTDxRWUPkzPSTwOog6of3OiEIFSbdiSrgM=.4a953820-b264-405e-be03-0bed8fce70e3@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <-owWLhz4rfTDxRWUPkzPSTwOog6of3OiEIFSbdiSrgM=.4a953820-b264-405e-be03-0bed8fce70e3@github.com>
Message-ID: <vzhJzVm8gw4_-jOH2oRUnBHHZcC0HQdzAC5wTRKK4XA=.66c2e9e3-44b6-469d-aca0-ab353e8ebc45@github.com>

On Tue, 7 Feb 2023 23:14:23 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update years. Add conditional

I ran the test on linux on GTK L&F. Screenshots of enabled/disabled JComboBoxes: 
![Screenshot 2023-02-08 125006](https://user-images.githubusercontent.com/90066231/217648359-1caf92ae-5df7-4812-b2a8-dc8669d49235.png)
![Screenshot 2023-02-08 125030](https://user-images.githubusercontent.com/90066231/217648362-4bae9ddb-8a5a-4f01-a053-95be832d458b.png)

They look fine to me.

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

PR: https://git.openjdk.org/jdk/pull/12390


From prr at openjdk.org  Wed Feb  8 21:04:52 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 21:04:52 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <GjEoc7gDBiOqf5772h5yTCgDEdYXM7JFRNMWSB1onHY=.878ba844-5200-4109-b939-63fdd3becd3e@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>
 <k936iKtvEA2hePHELvYlZyuhxywnnYnPiGC7a54J0AQ=.b72ff6c6-dd09-4a21-8926-880641e8620c@github.com>
 <-t6p4heuqGQwq2t_l-vKwFvGM_qz92H3PdwW4tKJpg0=.2d877e71-9a62-4f6b-84c3-74c49f1c8727@github.com>
 <txXotmyt5U_uhRQ38175kf8Jn42iKKxmfwF6shhMASo=.2fbf94f0-5b27-4670-9b59-a014e250488b@github.com>
 <GjEoc7gDBiOqf5772h5yTCgDEdYXM7JFRNMWSB1onHY=.878ba844-5200-4109-b939-63fdd3becd3e@github.com>
Message-ID: <1hO1e9mLXnG1moN9ilwETFeBKmMGzRcwR2viZrle90o=.e8c4c150-dc95-43c0-9971-70c7340bf867@github.com>

On Wed, 8 Feb 2023 20:12:28 GMT, Phil Race <prr at openjdk.org> wrote:

>>> if we create a caret, then call setBlinkRate(), and then install()
>>> then the blink rate appears to be ignored whereas before 4512626 it was applied.
>> 
>> Ok, if the text component is already visible and editable and focused and we install the new caret then the blink rate will not have an effect until the focus is lost and regained or until it became non-editable - and i think that was close to what we had before and there is a bug to investigate and optimize such corner case. In all other cases the code works fine. The value set is being preserved and will be reactivated when any of the methods such as focusGained or when the component installUI is called - if the cursor is set before component becomes visible - will cause to re-evaluate the blink rate and the stored value set by user will take place.
>
> Suppose I have this code
> 
> Caret c = new DefaultCaret()
> c.setBlinkRate(50);
> c.install(editableJComponent);
> 
> BEFORE 4512626 the JDK code looked like this
> 
>      if (rate != 0) {
>             if (flasher == null) {
>                 flasher = new Timer(rate, handler);
>             }
>             flasher.setDelay(rate);
>         }
> 
> 
> With your fix it looks like this
> 
>      if (rate != 0) {
>             if (component != null && component.isEditable()) {
>                if (flasher == null) {
>                    flasher = new Timer(rate, handler);
>                }
>              }
>         }
> 
> 
> So with my sample application code there's a change that my blink rate is completely lost.

So it seems that in such a case, "savedBlinkRate" is still set and that is used to both report the value of blink rate *and* create & start a Timer when it is needed.
It is a little hard to follow through all those "when it is needed" cases but if we are attached to an enabled & editable component when  focusGained() is called it should then start the flasher timer.

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

PR: https://git.openjdk.org/jdk20/pull/122


From dnguyen at openjdk.org  Wed Feb  8 21:11:44 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 8 Feb 2023 21:11:44 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <CgpsraezLr8k2n9_8eFpNfeYusF-zd2QjyhUkQZFOx0=.cd471c4c-a8f3-437c-9ffc-255d4147a649@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
 <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>
 <NndterQASTmoDb-A5Wj2ZDRfH6GtOaF4SFhAFg21wVM=.c48203de-5abe-4d0e-a000-b9fa6c7b8684@github.com>
 <hj9vlRUZYV8FN6qbc_djvyz8hKeGQ8gdRJDU2lTtie4=.e5fd9f91-8e5a-4404-8235-f3caa950ede2@github.com>
 <CgpsraezLr8k2n9_8eFpNfeYusF-zd2QjyhUkQZFOx0=.cd471c4c-a8f3-437c-9ffc-255d4147a649@github.com>
Message-ID: <iWiJxvUJol3N3f5iAm0yDFmIMQAUsiE4lChFvlxlkPA=.e85c4cef-3f5c-48c9-a704-aea3f54a2442@github.com>

On Wed, 8 Feb 2023 06:33:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > I created an automated test, but for some L&F's (such as Nimbus), an enabled vs disabled ComboBox differs in more than just the text color. The background, border, and button color may change as well
> 
> Then can we not compare the comboBox without DLCR with comboBox with DLCR when both are disabled...both should be same as per your screenshot

A comboBox with DLCR is slightly smaller than one without DLCR (138x25 vs 140x25). If I force the same dimensions with setSize, the RGB values are slightly off. If these comboBoxes are supposed to exactly match in dimensions, they currently don't, and this is due to what would be a separate bug if so.

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

PR: https://git.openjdk.org/jdk/pull/12390


From kizune at openjdk.org  Wed Feb  8 21:17:52 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 21:17:52 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <1hO1e9mLXnG1moN9ilwETFeBKmMGzRcwR2viZrle90o=.e8c4c150-dc95-43c0-9971-70c7340bf867@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <UCdw--NsFLNADOU47gawgo5OBu2bg1g5pmPk8gxKPaQ=.1bab1d70-6c3f-4634-8e64-ae33dd14a447@github.com>
 <k936iKtvEA2hePHELvYlZyuhxywnnYnPiGC7a54J0AQ=.b72ff6c6-dd09-4a21-8926-880641e8620c@github.com>
 <-t6p4heuqGQwq2t_l-vKwFvGM_qz92H3PdwW4tKJpg0=.2d877e71-9a62-4f6b-84c3-74c49f1c8727@github.com>
 <txXotmyt5U_uhRQ38175kf8Jn42iKKxmfwF6shhMASo=.2fbf94f0-5b27-4670-9b59-a014e250488b@github.com>
 <GjEoc7gDBiOqf5772h5yTCgDEdYXM7JFRNMWSB1onHY=.878ba844-5200-4109-b939-63fdd3becd3e@github.com>
 <1hO1e9mLXnG1moN9ilwETFeBKmMGzRcwR2viZrle90o=.e8c4c150-dc95-43c0-9971-70c7340bf867@github.com>
Message-ID: <scnr34XmtyK5yDWXtiARPoxEvbuFsC4hMmOharF2FsU=.1d037278-8b38-4dff-93aa-9356cdc78c9f@github.com>

On Wed, 8 Feb 2023 21:02:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Suppose I have this code
>> 
>> Caret c = new DefaultCaret()
>> c.setBlinkRate(50);
>> c.install(editableJComponent);
>> 
>> BEFORE 4512626 the JDK code looked like this
>> 
>>      if (rate != 0) {
>>             if (flasher == null) {
>>                 flasher = new Timer(rate, handler);
>>             }
>>             flasher.setDelay(rate);
>>         }
>> 
>> 
>> With your fix it looks like this
>> 
>>      if (rate != 0) {
>>             if (component != null && component.isEditable()) {
>>                if (flasher == null) {
>>                    flasher = new Timer(rate, handler);
>>                }
>>              }
>>         }
>> 
>> 
>> So with my sample application code there's a change that my blink rate is completely lost.
>
> So it seems that in such a case, "savedBlinkRate" is still set and that is used to both report the value of blink rate *and* create & start a Timer when it is needed.
> It is a little hard to follow through all those "when it is needed" cases but if we are attached to an enabled & editable component when  focusGained() is called it should then start the flasher timer.

Using the simple code like this one:
```        Caret caret = new DefaultCaret();
        caret.setBlinkRate(10);
        JFrame frame = new JFrame("test");
        JTextArea area = new JTextArea(null, "Some text to make it non-empty", 5, 40);
        area.setEditable(false);
        area.setCaret(caret);
        frame.setLayout(new BorderLayout());
        frame.add(area, BorderLayout.CENTER);
        frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
        frame.pack();
        frame.setVisible(true);
        SwingUtilities.invokeAndWait(() -> area.requestFocus(false));
        SwingUtilities.invokeAndWait(() -> area.setEditable(true));
        SwingUtilities.invokeAndWait(() -> {
            System.out.println(area.getCaret().getBlinkRate());
        });

i tested many possible combinations to see that the blink rate specified in setBlinkRate is preserved and not being overwritten by some code. In some corner cases the cursor does not blink despite reporting the correct blink rate until the focus is lost and regained - but that is still better than the version before JDK-4512626 where in the same corner case the cursor is not visible until the focus is lost and gained again. There is a bug JDK-8299048 that tracks the corner case i am talking about.

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

PR: https://git.openjdk.org/jdk20/pull/122


From prr at openjdk.org  Wed Feb  8 21:42:50 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 21:42:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
Message-ID: <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>

On Tue, 7 Feb 2023 23:23:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixe copyright year.

Another question, in the branch where the app calls
setBlinkRate(0)
we have
            if ((component == null || component.isEditable()) && isBlinkRateSaved) {
                savedBlinkRate = 0;
                isBlinkRateSaved = false;
            }

Why do we not clear these unconditionally ?
What is the point of saving it if there's a non-editable component ?

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 22:25:42 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 22:25:42 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
Message-ID: <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>

On Wed, 8 Feb 2023 21:40:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Why do we not clear these unconditionally ?
> What is the point of saving it if there's a non-editable component ?

Because then when we set component non-editable the stored blink rate will be lost and we will not be able to restore it when component will be switched to editable again. Same with the component not assigned - if we assign it to the non-editable component and then flip the editable property then we would not have the previous blink rate saved and will not know what value to set.

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 22:35:46 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 22:35:46 GMT
Subject: RFR: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled [v5]
In-Reply-To: <MlEUPB2T45M5xgVlYahStFtJX-iZV2hW2z_RJUnJdwE=.93193e6e-0444-4517-a4fc-edb4e6c6f8e1@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
 <MlEUPB2T45M5xgVlYahStFtJX-iZV2hW2z_RJUnJdwE=.93193e6e-0444-4517-a4fc-edb4e6c6f8e1@github.com>
Message-ID: <oJXaG_B-RGYad_PA03ZFyuqbQS39LTe0Xr_JnxpQR6E=.9edc9adf-2bd2-4713-9b60-a37121ef51b7@github.com>

On Tue, 7 Feb 2023 21:57:16 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
>> 
>> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.
>
> 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 12 additional commits since the last revision:
> 
>  - minor review changes
>  - Merge branch 'master' into MetalBorderRefactor_8294484
>  - review changes: AbstractMetalWindowBorder, strokeWidth rename
>  - Merge branch 'master' into MetalBorderRefactor_8294484
>  - minor change
>  - removed unused import
>  - added updateColor(), isActive() to MetalBorder
>  - test summary changes
>  - deleted InternalFrameBorderTest
>  - moved corner var to AbstractMetalBorder
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/19d1852a...e9b37edc

Looks good.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12391


From prr at openjdk.org  Wed Feb  8 22:48:50 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 22:48:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
 <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
Message-ID: <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>

On Wed, 8 Feb 2023 22:22:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > Why do we not clear these unconditionally ?
> > What is the point of saving it if there's a non-editable component ?
> 
> Because then when we set component non-editable the stored blink rate will be lost and we will not be able to restore it when component will be switched to editable again. Same with the component not assigned - if we assign it to the non-editable component and then flip the editable property then we would not have the previous blink rate saved and will not know what value to set.

I am not following .. this is about the branch where the app is setting blink rate to zero.
We surely don't want to keep the old blink rate just because a component is non-editable ?

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 23:02:44 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 23:02:44 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
 <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
 <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>
Message-ID: <x7pO7r3oeXeYAeNO7OO0kGh5gsGyCroAVbxuNxhf4j0=.adbe385b-0a25-4741-bfd8-3fac90f198b2@github.com>

On Wed, 8 Feb 2023 22:46:00 GMT, Phil Race <prr at openjdk.org> wrote:

> We surely don't want to keep the old blink rate just because a component is non-editable ?

When we receive focus on non-editable component we set blink rate to 0 to stop caret blinking. If we do not add this condition then we immediately clear off the saved blink rate.

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

PR: https://git.openjdk.org/jdk20/pull/122


From aivanov at openjdk.org  Wed Feb  8 23:03:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 8 Feb 2023 23:03:46 GMT
Subject: RFR: 8301443: Clean broken comments from Windows code [v7]
In-Reply-To: <6R_itk-rGsyjqyl0jNSC9LfGx9LC9cgFVBEy5oQAgYU=.90078df9-9a42-4ece-b334-e801a2129aef@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
 <6R_itk-rGsyjqyl0jNSC9LfGx9LC9cgFVBEy5oQAgYU=.90078df9-9a42-4ece-b334-e801a2129aef@github.com>
Message-ID: <_FDvJI7hd0i0SUCQffTxCntCkYsjCOjNppPn7YpwO5k=.fa19eac5-79c8-417d-96c1-6e1b60e0a493@github.com>

On Wed, 8 Feb 2023 08:36:03 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into comments
>  - Revert awt_List.cpp
>  - D3DVertexCacher.cpp
>  - awt_List.cpp
>  - sspi.cpp
>  - awt_Toolkit.cpp
>  - Merge branch 'openjdk:master' into comments
>  - Partial Revert
>  - sspi.cpp
>  - Comments

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12305


From prr at openjdk.org  Wed Feb  8 23:07:48 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 23:07:48 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <x7pO7r3oeXeYAeNO7OO0kGh5gsGyCroAVbxuNxhf4j0=.adbe385b-0a25-4741-bfd8-3fac90f198b2@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
 <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
 <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>
 <x7pO7r3oeXeYAeNO7OO0kGh5gsGyCroAVbxuNxhf4j0=.adbe385b-0a25-4741-bfd8-3fac90f198b2@github.com>
Message-ID: <Ptk0CA9av0OekYtsqXjTVT-ltdZ7V34zrQNZ7hdkQdA=.5409d739-c8e3-4321-a9d0-6b78662fdb85@github.com>

On Wed, 8 Feb 2023 22:59:35 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > We surely don't want to keep the old blink rate just because a component is non-editable ?
> 
> When we receive focus on non-editable component we set blink rate to 0 to stop caret blinking. If we do not add this condition then we immediately clear off the saved blink rate.

How do you tell that apart from the app directly clearing it ? ie the APP calling setBlinkRate(0) ?

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 23:10:52 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 23:10:52 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <Ptk0CA9av0OekYtsqXjTVT-ltdZ7V34zrQNZ7hdkQdA=.5409d739-c8e3-4321-a9d0-6b78662fdb85@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
 <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
 <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>
 <x7pO7r3oeXeYAeNO7OO0kGh5gsGyCroAVbxuNxhf4j0=.adbe385b-0a25-4741-bfd8-3fac90f198b2@github.com>
 <Ptk0CA9av0OekYtsqXjTVT-ltdZ7V34zrQNZ7hdkQdA=.5409d739-c8e3-4321-a9d0-6b78662fdb85@github.com>
Message-ID: <PyTaivsYESKRujVpyj2SwbZutdWV07omZfK_Bb-5nyU=.d6362e4a-3982-47f8-a357-901965a477ed@github.com>

On Wed, 8 Feb 2023 23:05:15 GMT, Phil Race <prr at openjdk.org> wrote:

> How do you tell that apart from the app directly clearing it ? ie the APP calling setBlinkRate(0) ?

I do not - while component is non-editable you can not change blink rate to 0, once the component will become editable the last non-zero value will be restored.

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

PR: https://git.openjdk.org/jdk20/pull/122


From prr at openjdk.org  Wed Feb  8 23:16:54 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 23:16:54 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <PyTaivsYESKRujVpyj2SwbZutdWV07omZfK_Bb-5nyU=.d6362e4a-3982-47f8-a357-901965a477ed@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
 <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
 <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>
 <x7pO7r3oeXeYAeNO7OO0kGh5gsGyCroAVbxuNxhf4j0=.adbe385b-0a25-4741-bfd8-3fac90f198b2@github.com>
 <Ptk0CA9av0OekYtsqXjTVT-ltdZ7V34zrQNZ7hdkQdA=.5409d739-c8e3-4321-a9d0-6b78662fdb85@github.com>
 <PyTaivsYESKRujVpyj2SwbZutdWV07omZfK_Bb-5nyU=.d6362e4a-3982-47f8-a357-901965a477ed@github.com>
Message-ID: <pKrfDGBZSkcY4v3ENvb37aexaMM-dKs8zOpScL62TH8=.cec42e6f-d8fe-4067-aac2-e4691412258e@github.com>

On Wed, 8 Feb 2023 23:07:40 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > How do you tell that apart from the app directly clearing it ? ie the APP calling setBlinkRate(0) ?
> 
> I do not - while component is non-editable you can not change blink rate to 0, once the component will become editable the last non-zero value will be restored.

But that seems wrong. Why is it not wrong ?

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 23:20:44 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 23:20:44 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <pKrfDGBZSkcY4v3ENvb37aexaMM-dKs8zOpScL62TH8=.cec42e6f-d8fe-4067-aac2-e4691412258e@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
 <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
 <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>
 <x7pO7r3oeXeYAeNO7OO0kGh5gsGyCroAVbxuNxhf4j0=.adbe385b-0a25-4741-bfd8-3fac90f198b2@github.com>
 <Ptk0CA9av0OekYtsqXjTVT-ltdZ7V34zrQNZ7hdkQdA=.5409d739-c8e3-4321-a9d0-6b78662fdb85@github.com>
 <PyTaivsYESKRujVpyj2SwbZutdWV07omZfK_Bb-5nyU=.d6362e4a-3982-47f8-a357-901965a477ed@github.com>
 <pKrfDGBZSkcY4v3ENvb37aexaMM-dKs8zOpScL62TH8=.cec42e6f-d8fe-4067-aac2-e4691412258e@github.com>
Message-ID: <FxkLQ2bm7YtnhhUquMqt_xI4CUR6xRqNtUPVolCXg6Y=.c006a5a6-bbac-4dbf-83b2-138618c4a4f2@github.com>

On Wed, 8 Feb 2023 23:14:18 GMT, Phil Race <prr at openjdk.org> wrote:

> But that seems wrong. Why is it not wrong ?

It might be an oversight of the initial fix, if you think it is wrong we can submit a bug and i can fix it. I definitely do not think it is critical and i do not think it is related to the nature of this change.

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

PR: https://git.openjdk.org/jdk20/pull/122


From prr at openjdk.org  Wed Feb  8 23:34:50 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 23:34:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <FxkLQ2bm7YtnhhUquMqt_xI4CUR6xRqNtUPVolCXg6Y=.c006a5a6-bbac-4dbf-83b2-138618c4a4f2@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <kDMeV0PSLGi4k8tTl4e0oHWqbHdiiBzX5NePYqkHUc0=.2cd064fb-cdf9-450e-9c90-4b8ed1417a0e@github.com>
 <_85FB-wlpMUNgy7ESLVjT_qKjv5BQpdXXPlv7NlmYhQ=.13ae5ac5-69ca-4a22-9cea-f4c28a9c347d@github.com>
 <MqXAGWsLwxO7OcsWpIwfS8X3VToUqBaUPoFmzHCGaKY=.fa93eda0-9b62-439f-80e3-efcf27dc62b4@github.com>
 <x7pO7r3oeXeYAeNO7OO0kGh5gsGyCroAVbxuNxhf4j0=.adbe385b-0a25-4741-bfd8-3fac90f198b2@github.com>
 <Ptk0CA9av0OekYtsqXjTVT-ltdZ7V34zrQNZ7hdkQdA=.5409d739-c8e3-4321-a9d0-6b78662fdb85@github.com>
 <PyTaivsYESKRujVpyj2SwbZutdWV07omZfK_Bb-5nyU=.d6362e4a-3982-47f8-a357-901965a477ed@github.com>
 <pKrfDGBZSkcY4v3ENvb37aexaMM-dKs8zOpScL62TH8=.cec42e6f-d8fe-4067-aac2-e4691412258e@github.com>
 <FxkLQ2bm7YtnhhUquMqt_xI4CUR6xRqNtUPVolCXg6Y=.c006a5a6-bbac-4dbf-83b2-138618c4a4f2@github.com>
Message-ID: <ZxOUWVpMcjIqv3DK1M0kCid__cbh-Z0QRevQbEyUZ-E=.8d443a34-1e90-4d7c-946d-6cf3f1931db5@github.com>

On Wed, 8 Feb 2023 23:17:59 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> > But that seems wrong. Why is it not wrong ?
> 
> It might be an oversight of the initial fix, if you think it is wrong we can submit a bug and i can fix it. I definitely do not think it is critical and i do not think it is related to the nature of this change.

Well .. it does seem wrong to me .. I was hoping you'd be able to explain why its OK.
That makes two "corner cases" to clean up in a later release.
Dilemma .. way too risky to try to clean that up now .. not sure if we want to back out the ENTIRE fix ... not sure about OKing a fix with known issues.
The only way I can look at it and convince myself is to consider that that corner case itself does not look like a P2 release stopper ..

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

PR: https://git.openjdk.org/jdk20/pull/122


From prr at openjdk.org  Wed Feb  8 23:41:50 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Feb 2023 23:41:50 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
Message-ID: <ux3DfFZOZfFbi7yvi7VExGBzqlSm3e1k9VWzWqQt280=.e8a87563-c7d6-4797-a06e-0730fa2cb296@github.com>

On Tue, 7 Feb 2023 23:23:24 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.
>
> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixe copyright year.

Approving as critical to fix the NPE.
There seems possible there may be followup work in a later release.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 23:58:52 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 23:58:52 GMT
Subject: [jdk20] RFR: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE [v2]
In-Reply-To: <ux3DfFZOZfFbi7yvi7VExGBzqlSm3e1k9VWzWqQt280=.e8a87563-c7d6-4797-a06e-0730fa2cb296@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
 <7FVJBE5Jh4m_89Yw3VraSOHm0cGisOmFfWTWYBuNQ2M=.6bbf6981-1f21-4480-bc21-76639e87405f@github.com>
 <ux3DfFZOZfFbi7yvi7VExGBzqlSm3e1k9VWzWqQt280=.e8a87563-c7d6-4797-a06e-0730fa2cb296@github.com>
Message-ID: <qr2sQaXO2EU4mQ9ZPiG9YgO7pSJHEMeyJiAoJYAS2MU=.f04c24d3-25d5-4e13-84c5-a063e2cf411b@github.com>

On Wed, 8 Feb 2023 23:39:19 GMT, Phil Race <prr at openjdk.org> wrote:

> Approving as critical to fix the NPE. There seems possible there may be followup work in a later release.

There will be.

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

PR: https://git.openjdk.org/jdk20/pull/122


From kizune at openjdk.org  Wed Feb  8 23:58:53 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 8 Feb 2023 23:58:53 GMT
Subject: [jdk20] Integrated: 8301989: new
 javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE
In-Reply-To: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
References: <F9xHfQUPo-waJq6nn0oPofaQofBDJBDnZphhnnHkTxI=.91d7f4eb-59f6-4d01-8d8f-d4f9ef685961@github.com>
Message-ID: <nFS5HA6OhJ1u91byz5kH37g299zZH3bzG4yq-t_SNzU=.30619a30-eead-4cc1-bee3-01e13d3b8d72@github.com>

On Tue, 7 Feb 2023 22:49:55 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> Check if the component is associated with the caret before calling methods from it. Added test case that will make sure that will not happen again.

This pull request has now been integrated.

Changeset: e81f20b5
Author:    Alexander Zuev <kizune at openjdk.org>
URL:       https://git.openjdk.org/jdk20/commit/e81f20b50405dc02963c8bf549000c60e78152d8
Stats:     49 lines in 2 files changed: 46 ins; 0 del; 3 mod

8301989: new javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE

Reviewed-by: dnguyen, honkar, prr

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

PR: https://git.openjdk.org/jdk20/pull/122


From honkar at openjdk.org  Thu Feb  9 00:48:03 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 9 Feb 2023 00:48:03 GMT
Subject: Integrated: JDK-8294484: MetalBorder's FrameBorder & DialogBorder have
 border rendering issues when scaled
In-Reply-To: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
References: <3mOa2qVTOH04ZqC_X7P3Y-el2neZcqhjrkTio6TnLaY=.67abc987-33bd-48aa-bb12-c8deac57699a@github.com>
Message-ID: <v72ZZlFNK6NAaqfYQoIbCPRrzpYaW4inEx7wUCoFL0g=.d6583368-5fa0-4dfb-b03a-f092118112de@github.com>

On Thu, 2 Feb 2023 20:09:18 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> FrameBorder and DialogBorder had border scaling issues similar to JInternalFrame. This fix addresses it by creating `AbstractMetalWindowBorder` class within MetalBorder, that contains the common steps required for painting border for `FrameBorder`, `DialogBorder` and `InternalFrameBorder`. 
> 
> All 3 cases - JFrame, JDialog and JInternalFrame are combined into a single test case - `ScaledMetalBorderTest` and hence the older `InternalFrameBorderTest` which is no longer required, is deleted.

This pull request has now been integrated.

Changeset: 5561c397
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5561c397c53b8a821a200491abd8f7b3297fbd31
Stats:     797 lines in 3 files changed: 393 ins; 328 del; 76 mod

8294484: MetalBorder's FrameBorder & DialogBorder have border rendering issues when scaled

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: aivanov, kizune

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

PR: https://git.openjdk.org/jdk/pull/12391


From dnguyen at openjdk.org  Thu Feb  9 01:07:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 9 Feb 2023 01:07:46 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v5]
In-Reply-To: <BNIwaUoZeA5UHAI3ufXc2eg_MutxZpnJh1R9TUuBA00=.73441346-36ec-4ec0-9ab5-6a7273a17ace@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <-owWLhz4rfTDxRWUPkzPSTwOog6of3OiEIFSbdiSrgM=.4a953820-b264-405e-be03-0bed8fce70e3@github.com>
 <BNIwaUoZeA5UHAI3ufXc2eg_MutxZpnJh1R9TUuBA00=.73441346-36ec-4ec0-9ab5-6a7273a17ace@github.com>
Message-ID: <tcYJkLTViAr_TjiSN7mcqPmBEt-B1T85XxGvCjV7hXs=.4f13ad9b-4caf-45d3-b262-d4a3a6cd2990@github.com>

On Wed, 8 Feb 2023 06:32:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> `SynthComboBoxUI.createRenderer` points to `SynthComboBoxRenderer `so I think `DefaultListCellRenderer `should not come into picture for rendering cells in the list which should go via `getListCellRendererComponent`. If it is playing a part, then how it works in other L&F which also has it own renderer (for example, `BasicComboBoxUI.createRenderer` points to `BasicComboBoxRenderer`, AquaComboBox points to `AquaComboBoxRenderer`) and they dont have this listener to make it work, so the question why do we need a listener for Synth still not clear to me..

I thought the same, but Nimbus seems to act different for this instance only. I traced the conditional in SynthComboBoxRenderer, and this was added in Apr 25, 2009 [here](https://github.com/openjdk/jdk/commit/c738ebdc6789068c3faf9e656bd4c02f84fe82bc#diff-54280d4d928e7579aa04324bb7d0a306f621b92d77d0dc508d8a269c124664a8). This seems like the introduction of Nimbus and how it's enabled/disabled ComboBoxes for Nimbus, with the oversight of setting a different renderer. This looks like the only OS that does this like you mentioned. The reason why this need to setEnabled in the renderer for Nimbus wasn't stated in the comment or bug description page. But it does seem to still need it as this was the only fix I found.

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

PR: https://git.openjdk.org/jdk/pull/12390


From serb at openjdk.org  Thu Feb  9 02:55:51 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 9 Feb 2023 02:55:51 GMT
Subject: RFR: 8301822: BasicLookAndFeel does not need to check for null
 after checking for type
In-Reply-To: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
References: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
Message-ID: <f00c-Y3guhXg7q2lt2oNMSiLKhJ9xZWOP8rGDonw6Rs=.2da25dbd-657d-4585-9a6e-fcb30b540b40@github.com>

On Mon, 16 Jan 2023 20:30:08 GMT, SWinxy <duke at openjdk.org> wrote:

> BasicLookAndFeel checks an instanceof in its `AWTEventHelper` listener class, but the result of that will always be non-null. The check should be removed.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12019


From psadhukhan at openjdk.org  Thu Feb  9 02:59:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 9 Feb 2023 02:59:11 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v5]
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <57-FqOLxWg4kYTkdif8qua-zX9szU-9HYN7ghdA1cYs=.0627bcd0-d72b-4d24-b677-e1366f89971e@github.com>

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

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

  Update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12180/files
  - new: https://git.openjdk.org/jdk/pull/12180/files/cd4cb65a..dbeb36dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=03-04

  Stats: 29 lines in 1 file changed: 3 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/12180.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12180/head:pull/12180

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Thu Feb  9 02:59:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 9 Feb 2023 02:59:11 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v4]
In-Reply-To: <BvvaVj_ywvQdL4G5gXeTWfw33niTKV1mIpxEjSS1sPk=.f2190474-b5f2-4084-b78f-528541bc0eb0@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <uS7OfjwX0gWr-7sfhvnrHWrWPCyruOsg0eK8h5wWN-s=.94493fb6-66d2-4293-971b-aaec3f2431d4@github.com>
 <BvvaVj_ywvQdL4G5gXeTWfw33niTKV1mIpxEjSS1sPk=.f2190474-b5f2-4084-b78f-528541bc0eb0@github.com>
Message-ID: <Wk37WFwGRsMdTMfPu1Ru_OZMZVygd2Y0DNPV2Nu8cZI=.4f0513c7-bed9-46ac-89ed-40426a41202d@github.com>

On Wed, 8 Feb 2023 11:44:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jcheck fix
>
> test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 53:
> 
>> 51:             SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));
>> 52:             JFileChooser fc = new JFileChooser();
>> 53:             Font origFont = fc.getFont();
> 
> This is really inconsistent: you set L&F on EDT but you create `JFileChooser` on main thread. You should either do everything on main thread or, preferably, move all the test code onto EDT.

ok

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

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Thu Feb  9 03:10:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 9 Feb 2023 03:10:12 GMT
Subject: RFR: JDK-7154070: in SwingSet2,
 switching between LaFs it's easy to lose JTable dividers [v6]
In-Reply-To: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
References: <xWUA_8bZi5CYYCqhCdsWS3WBoXgCHwwkAzzz3LlVbp0=.bcdc17de-1da4-45dd-8a1c-caeda3a04140@github.com>
Message-ID: <M1WcIeXUtS9_M3nG87nTKdsNCJt-plGtfoUE4aDF5jA=.ebd26fc4-e713-4d1a-a5a5-975e72de0a40@github.com>

> In SwingSet2 in TableDemo, we can see grid dividers in Metal L&F but 
> if we Switch to the Nimbus LaF which has no grid dividers by default and then if we switch to Java (Metal): it will show no dividers.
> 
> Issue is Nimbus call JTable.showGrid(false) in installDefaults but fail to reset in uninstallDefaults which is now rectified.
> 
> No regression test is added as it can be verified by SwingSet2 Tabledemo..

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

  Fix and test updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12385/files
  - new: https://git.openjdk.org/jdk/pull/12385/files/1a456cc7..b10f6c2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12385&range=04-05

  Stats: 22 lines in 2 files changed: 3 ins; 14 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12385.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12385/head:pull/12385

PR: https://git.openjdk.org/jdk/pull/12385


From psadhukhan at openjdk.org  Thu Feb  9 03:23:41 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 9 Feb 2023 03:23:41 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <iWiJxvUJol3N3f5iAm0yDFmIMQAUsiE4lChFvlxlkPA=.e85c4cef-3f5c-48c9-a704-aea3f54a2442@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
 <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>
 <NndterQASTmoDb-A5Wj2ZDRfH6GtOaF4SFhAFg21wVM=.c48203de-5abe-4d0e-a000-b9fa6c7b8684@github.com>
 <hj9vlRUZYV8FN6qbc_djvyz8hKeGQ8gdRJDU2lTtie4=.e5fd9f91-8e5a-4404-8235-f3caa950ede2@github.com>
 <CgpsraezLr8k2n9_8eFpNfeYusF-zd2QjyhUkQZFOx0=.cd471c4c-a8f3-437c-9ffc-255d4147a649@github.com>
 <iWiJxvUJol3N3f5iAm0yDFmIMQAUsiE4lChFvlxlkPA=.e85c4cef-3f5c-48c9-a704-aea3f54a2442@github.com>
Message-ID: <nKYC66BXLf5yaHW0ahZc_k2d6N6ipCnDrCJ4_L9438g=.ab1b824d-a94d-4b96-8e80-efa449e1fe5c@github.com>

On Wed, 8 Feb 2023 21:08:39 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> > > I created an automated test, but for some L&F's (such as Nimbus), an enabled vs disabled ComboBox differs in more than just the text color. The background, border, and button color may change as well
> > 
> > 
> > Then can we not compare the comboBox without DLCR with comboBox with DLCR when both are disabled...both should be same as per your screenshot
> 
> A comboBox with DLCR is slightly smaller than one without DLCR (138x25 vs 140x25). If I force the same dimensions with setSize, the RGB values are slightly off. If these comboBoxes are supposed to exactly match in dimensions, they currently don't, and this is due to what would be a separate bug if so.

maybe you can try to compare the mid scanline rather than the whole rectangle

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

PR: https://git.openjdk.org/jdk/pull/12390


From jwaters at openjdk.org  Thu Feb  9 03:23:52 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 9 Feb 2023 03:23:52 GMT
Subject: Integrated: 8301443: Clean broken comments from Windows code
In-Reply-To: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
References: <Nz5EArhUgwMue3kk1X5OYrsuguzH6LPsbRRjLtvmp6s=.9dbdbc2f-e099-4e86-b3ec-4fecf93b3472@github.com>
Message-ID: <AZ91hg5AdgTOQjiD7GElkAaYRj0vRB6qtoR3lnyRJvM=.c4012eae-ec8c-4aa3-b97b-215ab5bee227@github.com>

On Tue, 31 Jan 2023 06:28:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Several comments are technically broken in Windows code, this change cleans up the broken comments that managed to slip past reviewers during Integration

This pull request has now been integrated.

Changeset: 70f31501
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/70f3150166a758fe9fa14860588218ef41c2bff4
Stats:     27 lines in 12 files changed: 2 ins; 1 del; 24 mod

8301443: Clean broken comments from Windows code

Reviewed-by: aivanov

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

PR: https://git.openjdk.org/jdk/pull/12305


From ysuenaga at openjdk.org  Thu Feb  9 06:49:52 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:49:52 GMT
Subject: RFR: 8301855: C4819 warnings were reported in harfbuzz on Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <45OH0CS2Bn_Rg6AP_HCaZpJTnxUXV90H3yRQAwKNPK4=.aeac99b4-9216-4dbf-8b63-d0238c768b3e@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This issue will be treated in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)

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

PR: https://git.openjdk.org/jdk/pull/12437


From ysuenaga at openjdk.org  Thu Feb  9 06:49:53 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:49:53 GMT
Subject: Withdrawn: 8301855: C4819 warnings were reported in harfbuzz on
 Windows
In-Reply-To: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
References: <t5RNhvY_qr_LsQ9XO3cCKbcS0usDC-Z73N6J7_NJlpk=.aff4dc7b-492f-4796-ac3c-2a1e5cae8cbc@github.com>
Message-ID: <VtwSBI44mPS1foCHbqHo1HaM7vVW6rJVnLp8D0qL2kA=.4907c9d6-63f7-4dbf-8e05-7442fea638f3@github.com>

On Mon, 6 Feb 2023 12:35:16 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in harfbuzz files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): error C2220: ?????????????????
> d:\github-forked\jdk\src\java.desktop\share\native\libharfbuzz\hb.hh(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12437


From ysuenaga at openjdk.org  Thu Feb  9 06:50:53 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:50:53 GMT
Subject: RFR: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <jnDkh-pRd4AUSguXSVO0I0crrExfDd7HGSEYXf5OHmY=.ea9673bc-f65d-4d35-b5ed-fd4bc1977b7f@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This issue will be treated in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971)

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

PR: https://git.openjdk.org/jdk/pull/12436


From ysuenaga at openjdk.org  Thu Feb  9 06:50:53 2023
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 9 Feb 2023 06:50:53 GMT
Subject: Withdrawn: 8301854: C4819 warnings were reported in libfreetype on
 Windows
In-Reply-To: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
References: <28om_GU9c1-0s1BuN28AHNUyDMo-JiCwQNZNWkV4qCQ=.4b523305-b124-4b29-919c-e46961cbb27e@github.com>
Message-ID: <673wm8gRq6UD5GruLDma1RejnQWQBytTzafsszGncE0=.21427eab-4192-4b23-9cc9-00fc9d950044@github.com>

On Mon, 6 Feb 2023 12:34:36 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> This is subtask of https://github.com/openjdk/jdk/pull/12427 .
> 
> I have seen C4819 warning in libfreetype files on Windows (CP932: Japanese locale)
> 
> 
> d:\github-forked\jdk\src\java.desktop\share\native\libfreetype\src\autofit\afscript.h(1): warning C4819: ???????????? ??? (932) ??????????????????????????????????? Unicode ????????????
> 
> 
> I added C4819 to DISABLED_WARNINGS_microsoft for libfontmanager and for libfreetype because they are 3rd-party libraries.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12436


From jwilhelm at openjdk.org  Thu Feb  9 07:49:49 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 9 Feb 2023 07:49:49 GMT
Subject: RFR: Merge jdk20
Message-ID: <FSx6A_Vz1okUT1ctC5bJP9l7E5fx-f2eltAgnJly1Zc=.1fb6f527-f4e3-4538-86da-21c44dd02a16@github.com>

Forwardport JDK 20 -> JDK 21

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

Commit messages:
 - Merge remote-tracking branch 'jdk20/master' into Merge_jdk20
 - 8301989: new javax.swing.text.DefaultCaret().setBlinkRate(N) results in NPE
 - 8301863: ObjectInputFilter example incorrectly calls rejectUndecidedClass

The merge commit only contains trivial merges, so no merge-specific webrevs have been generated.

Changes: https://git.openjdk.org/jdk/pull/12484/files
  Stats: 69 lines in 3 files changed: 50 ins; 9 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/12484.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12484/head:pull/12484

PR: https://git.openjdk.org/jdk/pull/12484


From aturbanov at openjdk.org  Thu Feb  9 09:11:29 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 9 Feb 2023 09:11:29 GMT
Subject: RFR: 8302120: Prefer ArrayList to LinkedList in AggregatePainter
Message-ID: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>

There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

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

Commit messages:
 - [PATCH] Prefer ArrayList to LinkedList in AggregatePainter

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

PR: https://git.openjdk.org/jdk/pull/12254


From serb at openjdk.org  Thu Feb  9 09:11:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 9 Feb 2023 09:11:30 GMT
Subject: RFR: 8302120: Prefer ArrayList to LinkedList in AggregatePainter
In-Reply-To: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
References: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
Message-ID: <gVF81_zX_1pB1HzlkZ8MXsSUnhAYVsX5Qt6_R1lT1D4=.6b96aa83-edb4-4e51-a09d-44e4df773796@github.com>

On Fri, 27 Jan 2023 13:26:28 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

Looks fine.

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

PR: https://git.openjdk.org/jdk/pull/12254


From jwilhelm at openjdk.org  Thu Feb  9 12:02:54 2023
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 9 Feb 2023 12:02:54 GMT
Subject: Integrated: Merge jdk20
In-Reply-To: <FSx6A_Vz1okUT1ctC5bJP9l7E5fx-f2eltAgnJly1Zc=.1fb6f527-f4e3-4538-86da-21c44dd02a16@github.com>
References: <FSx6A_Vz1okUT1ctC5bJP9l7E5fx-f2eltAgnJly1Zc=.1fb6f527-f4e3-4538-86da-21c44dd02a16@github.com>
Message-ID: <GtgM6SXWQ2Sys3OsECMGaxD59trDmKT-PLt0JZ1dcdI=.3124732a-7e60-42c0-9176-6e40c0d4ec55@github.com>

On Thu, 9 Feb 2023 07:43:28 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 20 -> JDK 21

This pull request has now been integrated.

Changeset: af8973dc
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af8973dc509c1f326223e3ffd1773c9e930141d8
Stats:     69 lines in 3 files changed: 50 ins; 9 del; 10 mod

Merge

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

PR: https://git.openjdk.org/jdk/pull/12484


From duke at openjdk.org  Thu Feb  9 17:49:55 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 9 Feb 2023 17:49:55 GMT
Subject: Integrated: 8301822: BasicLookAndFeel does not need to check for null
 after checking for type
In-Reply-To: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
References: <o7eQkUan-iOBaGSo9O9Qqyr5TZlfJG9NYmZrNWiEgTA=.0a9d91bc-4232-4eae-b50f-52b4126ace25@github.com>
Message-ID: <X0LWMdulupMHyA6B4wC5ePOHe19jB_t6t7W4AQJcAZM=.a65bb819-e0f4-4925-a1d8-3fba4561514f@github.com>

On Mon, 16 Jan 2023 20:30:08 GMT, SWinxy <duke at openjdk.org> wrote:

> BasicLookAndFeel checks an instanceof in its `AWTEventHelper` listener class, but the result of that will always be non-null. The check should be removed.

This pull request has now been integrated.

Changeset: 597a9a48
Author:    SWinxy <swinxythecat at gmail.com>
Committer: Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/597a9a485216f6d5b1082eebfa1029524f247e8d
Stats:     16 lines in 1 file changed: 2 ins; 5 del; 9 mod

8301822: BasicLookAndFeel does not need to check for null after checking for type

Reviewed-by: serb

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

PR: https://git.openjdk.org/jdk/pull/12019


From serb at openjdk.org  Thu Feb  9 19:27:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 9 Feb 2023 19:27:58 GMT
Subject: Integrated: 8272288: Funky multiresolution image breaks graphics
 context
In-Reply-To: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
References: <v6GtuWIiXG4SzSCdmVGlwdf0hEEVHrZureMEm5NqcUE=.e5d62f8b-6a2f-429e-923a-1c05385f69ac@github.com>
Message-ID: <7tiOvjnFzuFPnlgfdQZ_hIS96k-7CRTwvzfu7Ux4QVQ=.a9380a87-6fe6-4aa3-9e9f-7f1b5f44cae3@github.com>

On Wed, 14 Dec 2022 08:20:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This is the next iteration of fixing the issue of rendering "broken" image. The fix for [JDK-7183828](https://bugs.openjdk.org/browse/JDK-7183828) changed the possible IllegalArgumentException during rendering to the InvalidPipeException in assumtion that the new exception will be catched by the java2d machinery and the current-accelerated pipeline will be invalidated and software-pipeline will take care about that image.
> 
> But that change uncover another bug, the accelerated-pipeline invalidation by the InvalidPipeException works in D3D pipeline only, other pipelines start to use software based surfaces, but do not report about that the client code, as a result the next code does not work as expected, since contentsLost alwys return false:
> 
>         do {
>             vi.validate(gc);
>             Graphics2D g = vi.createGraphics();
>             g.fillRect(0, 0, vi.getWidth(), vi.getHeight());
>             g.dispose();
>         } while (vi.contentsLost());
> 
> After this change the correct value will be reported by the contentsLost(), so the RepaintManager will be able to catch that.
> But this fix uncovered another bug. That fallback code path in the RepaintManager was not tested on HiDPI screen and does not work well. I'll file a separate bug about that.

This pull request has now been integrated.

Changeset: 51479692
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5147969253a9792d883fdd505a62b959c5541566
Stats:     157 lines in 3 files changed: 143 ins; 12 del; 2 mod

8272288: Funky multiresolution image breaks graphics context

Reviewed-by: jdv

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

PR: https://git.openjdk.org/jdk/pull/11664


From serb at openjdk.org  Thu Feb  9 19:44:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 9 Feb 2023 19:44:54 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <x2ilcjEu2--mEt3EuOa3_RxFpAa4jZWHoDn9mUQlTcI=.7760a448-0062-4516-a6fc-1e2664f2dab3@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
 <x2ilcjEu2--mEt3EuOa3_RxFpAa4jZWHoDn9mUQlTcI=.7760a448-0062-4516-a6fc-1e2664f2dab3@github.com>
Message-ID: <5OTRR04Dy1WnIX-P1xGwjmLRrGlCQphGPjaj5DyUUls=.ba98ddff-d99f-454d-99e0-767d912eba7c@github.com>

On Fri, 23 Dec 2022 23:03:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zuev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Simplifying the two nested if conditions into one.
>
> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 373:
> 
>> 371:     // --- FocusListener methods --------------------------
>> 372: 
>> 373:     /**
> 
> I guess everybody noticed the specification of this method.
>>This is implemented to set the caret to visible if the component is editable.
> 
> That should be updated? And overall it seems the whole behavior change required CSR.

ping

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

PR: https://git.openjdk.org/jdk20/pull/68


From aivanov at openjdk.org  Thu Feb  9 20:11:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Feb 2023 20:11:52 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v14]
In-Reply-To: <PwPlV_SYqbhZ4gFkXgLfQi7HZeJVYsPvuWcsiWMeeGg=.3711aca0-106a-4409-9292-04cc2bf579eb@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <PwPlV_SYqbhZ4gFkXgLfQi7HZeJVYsPvuWcsiWMeeGg=.3711aca0-106a-4409-9292-04cc2bf579eb@github.com>
Message-ID: <u3kj8wo_lsSrsrdLWm8Z7KUYTEV5Ur4f1X25ZGDfSjI=.eb0dbbd8-aa8a-4012-b3de-4ff0dec2bbfd@github.com>

On Wed, 8 Feb 2023 09:46:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updated

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 94:

> 92:                     // before doInBackground started running
> 93:                     if (!doInBackground &&
> 94:                          worker.getState() == SwingWorker.StateValue.STARTED) {

This condition doesn't guarantee that `STARTED` state is set before `doInBackground` starts running. The boolean flag is set to `true` only in the end of the method.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 106:

> 104:                         throw new RuntimeException(
> 105:                             "PropertyChangeListeners called after " +
> 106:                             " doInBackground is finised but before State changed to DONE");

Suggestion:

                            " doInBackground is finished but before State changed to DONE");

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  9 20:14:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Feb 2023 20:14:49 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v13]
In-Reply-To: <G35-M5X7jh24nv-olEAPHwBQEgQ6c_YpVhHrSXDuB44=.6edbead1-e15e-415e-9e76-a35c34cb94d8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <OZNhKFK-aQRDBye3AE_6SqkeC_edGS0rTn_GyyqM5Ug=.117e492d-bb7e-40f4-ac7e-c99861975677@github.com>
 <QsSZCEUWZ4oAi4u7p1g2gM_FVg1UK55IHT1cw6DATzY=.40a01aa3-f4d2-454b-96e2-56e92ac06a52@github.com>
 <G35-M5X7jh24nv-olEAPHwBQEgQ6c_YpVhHrSXDuB44=.6edbead1-e15e-415e-9e76-a35c34cb94d8@github.com>
Message-ID: <zWQqEuOFfPrDRXmi5_XdIsw71t8KLM0wCtRxIyeV7NM=.677d5921-90c4-481a-801d-616489033a0c@github.com>

On Wed, 8 Feb 2023 05:45:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > Since a CSR is required, I suggest updating the spec for `isDone` method so that it returns `true` only after `doInBackground` exits. Now `isDone` returns `true` after `cancel` completes but the `DONE` state isn't reached yet.
> 
> My take is current code fix and spec clarification is done to make code/spec wording consistent with **existing** spec whereas this change is to **enhance** the code/spec which I think we should keep it separate from this fix, as this will cause JCK test to be excluded and will cause JCK to update the test and I am not sure how that will pan out, so I suggest to keep the change to minimal to the extent only which is needed for this fix..

Reasonable.

Will you submit a low-priority enhancement then?

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  9 20:26:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Feb 2023 20:26:50 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <j37D6mSZl1FHsrod_L3yJUSO7lr3X3UltjvsqTM279c=.7deeb0b3-7df1-4b2e-85e3-da2bd72b9f2d@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
 <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
 <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>
 <BmWGzAsMYD3uO8GxInm-9MNHKzOB9Q5yCl269RhqN9I=.a8671024-3f4e-45bd-9f3e-2154d6febeeb@github.com>
 <tj7oXDRuT8PgjJEAHt8bLT8BCRA-S4oeukY
 jgODQLSc=.2d009358-9b1c-4273-bb45-2a71328ec694@github.com>
 <0ZbxygIwSrtMb9n4Bm3DI1FpaUi_oNq2LIoVc9NyzFE=.1b52621f-14a5-4eb8-ab2f-c6e3d6954b98@github.com>
 <j37D6mSZl1FHsrod_L3yJUSO7lr3X3UltjvsqTM279c=.7deeb0b3-7df1-4b2e-85e3-da2bd72b9f2d@github.com>
Message-ID: <5wOOv8uKsKkMzm116od0Zk56WwQr-2h2dYL-MCd_4bE=.36717833-d40b-444d-a2cd-fd914d5e332b@github.com>

On Wed, 8 Feb 2023 01:22:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > The specification isn't clear, and some parts somewhat contradict each other. Logically, the state should transition to `DONE` as soon as `doInBackground` completes. Then both done method and listeners are called when the state is `DONE` that is the background work is complete.
> 
> Which parts are contradicts?

This was a wrong statement. In fact, I referred to the problem that is being fixed here: `done` may be called before `doInBackground`.

https://github.com/openjdk/jdk/blob/0aeebee284effe9abd0ed3cf2845430b40bb53bd/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293

The spec for `DONE` state does not specify when the transition occurs.

> I mean that the old implementation call DONE-listener last, as specified in the header of the class what part of the spec mention different behavior?

Yes, this is how it's specified now.

> Above we discussed that it is possible to see a difference if the listener will do some work on EDT, after the fix the listener will not be called last, is that safe to assume it does not break something?

What kind of difference? Yes, you can observe the fact that now the `DONE`-state-listener is called before the `done` method.

In either case, the listener and the method are called when `get` does not block. The background job is finished when either of these events occurs.

I see no problem here.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  9 20:36:56 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Feb 2023 20:36:56 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v10]
In-Reply-To: <5wOOv8uKsKkMzm116od0Zk56WwQr-2h2dYL-MCd_4bE=.36717833-d40b-444d-a2cd-fd914d5e332b@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gd8hi51SI-B4wLbn9JIMUgicqpuWvmLyF-g21Cig0BQ=.6b6d9d5f-88bc-4b86-8bdb-3ee3307a6fbd@github.com>
 <BjsTPO9xYWjkpXvQbBpJ3lAlZqiKTwCo2mudCh4U_SQ=.f1e0da92-9112-4123-807e-316fe4ff8353@github.com>
 <4mVHHUaXIcoAJlIz2IDATepd5e0MbF9F-xVi1KLgSnQ=.3d7b61a7-e049-4606-a03b-a2f5e32add3b@github.com>
 <CgiLFFFiLejGjOSoizd-JOcqSiENR4uN1IKfYZXEPTc=.6c2be04c-3ebf-4b66-9626-61301ff1056c@github.com>
 <YZL_Rjz5QGiP8PscplFXW3Om9Qn3A7vim73eqQ9yCps=.ea0ac7a2-674c-414d-905c-d0ab7babfced@github.com>
 <vRKMa7l_t4klOkQ3YeJ8Y_KF4RdR9ZEXAkYGmz-Dx-g=.2554c28d-a63a-4a77-bfc6-18581e7600a0@github.com>
 <gsHmngegEXmCfxXCORSSRY4b3JLNaPBPkiZUJ_pkVyM=.696d4b88-a906-429a-9173-b3412d686330@github.com>
 <zcPu1sDb7kufgwfJQtIGOWW7Ol7kJQL_y7Hb5eblz5Q=.b71a0f49-db50-49d2-a3da-e6ef6aec01d9@github.com>
 <BmWGzAsMYD3uO8GxInm-9MNHKzOB9Q5yCl269RhqN9I=.a8671024-3f4e-45bd-9f3e-2154d6febeeb@github.com>
 <tj7oXDRuT8PgjJEAHt8bLT8BCRA-S4oeukY
 jgODQLSc=.2d009358-9b1c-4273-bb45-2a71328ec694@github.com>
 <0ZbxygIwSrtMb9n4Bm3DI1FpaUi_oNq2LIoVc9NyzFE=.1b52621f-14a5-4eb8-ab2f-c6e3d6954b98@github.com>
 <j37D6mSZl1FHsrod_L3yJUSO7lr3X3UltjvsqTM279c=.7deeb0b3-7df1-4b2e-85e3-da2bd72b9f2d@github.com>
 <5wOOv8uKsKkMzm116od0Zk56WwQr-2h2dYL-MCd_4bE=.36717833-d40b-444d-a2cd-fd914d5e332b@github.com>
Message-ID: <m98QoAfCAVPXytYv_I0K38QGRlLsZJT4Hcgx7g9B5Zg=.6f67113d-d712-48ea-b099-c7ef14bba1b9@github.com>

On Thu, 9 Feb 2023 20:24:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> The specification isn't clear, and some parts somewhat contradict each other. Logically, the state should transition to DONE as soon as doInBackground completes. Then both done method and listeners are called when the state is DONE that is the background work is complete.
>> 
>> Which parts are contradicts? I mean that the old implementation call DONE-listener last, as specified in the header of the class what part of the spec mention different behavior? Above we discussed that it is possible to see a difference if the listener will do some work on EDT, after the fix the listener will not be called last, is that safe to assume it does not break something?
>
>> > The specification isn't clear, and some parts somewhat contradict each other. Logically, the state should transition to `DONE` as soon as `doInBackground` completes. Then both done method and listeners are called when the state is `DONE` that is the background work is complete.
>> 
>> Which parts are contradicts?
> 
> This was a wrong statement. In fact, I referred to the problem that is being fixed here: `done` may be called before `doInBackground`.
> 
> https://github.com/openjdk/jdk/blob/0aeebee284effe9abd0ed3cf2845430b40bb53bd/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293
> 
> The spec for `DONE` state does not specify when the transition occurs.
> 
>> I mean that the old implementation call DONE-listener last, as specified in the header of the class what part of the spec mention different behavior?
> 
> Yes, this is how it's specified now.
> 
>> Above we discussed that it is possible to see a difference if the listener will do some work on EDT, after the fix the listener will not be called last, is that safe to assume it does not break something?
> 
> What kind of difference? Yes, you can observe the fact that now the `DONE`-state-listener is called before the `done` method.
> 
> In either case, the listener and the method are called when `get` does not block. The background job is finished when either of these events occurs.
> 
> I see no problem here.

> > It could be tested by flushing and blocking the EDT in the listener. That will allow us to check the order of events posted from the listener and from the "doneEDT".
> 
> Is flushing required?
> 
> Two `AtomicBoolean`s should do the job.

I referred to `isStateDoneNotified` and `isDoneCalled`.

> EDT can't process two events simultaneously, one follows the other. So, `done` is expected to be called while both are `false`, and it sets its own flag to `true`; the listener should be called second, so its flag is `false` and `done`'s flag is `true`.

Do we want to ensure it?

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Thu Feb  9 20:50:47 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Feb 2023 20:50:47 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v5]
In-Reply-To: <57-FqOLxWg4kYTkdif8qua-zX9szU-9HYN7ghdA1cYs=.0627bcd0-d72b-4d24-b677-e1366f89971e@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <57-FqOLxWg4kYTkdif8qua-zX9szU-9HYN7ghdA1cYs=.0627bcd0-d72b-4d24-b677-e1366f89971e@github.com>
Message-ID: <9Du5nigecJsxFxb-ZOJoPYdxWHtf3VV2zgYyTqgTfkA=.33d41c28-d54e-4e6c-9ace-f2686625a38f@github.com>

On Thu, 9 Feb 2023 02:59:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 69:

> 67:                     Font curFont = fc.getFont();
> 68:                     System.out.println("current font " + curFont);
> 69:                     if (curFont != null && !curFont.equals(origFont)) {

Is it valid that `currFont` is `null`?

Do we expect that `origFont.equals(curFont)` returns `true`? And I assume `origFont` shouldn't be `null` either. So the condition could be simplified to

Suggestion:

                    if (!origFont.equals(curFont)) {

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 71:

> 69:                     if (curFont != null && !curFont.equals(origFont)) {
> 70:                         throw new RuntimeException(
> 71:                          "JFileChooser font did not reset after Look & Feel change");

Suggestion:

                         "JFileChooser font is not reset after Look & Feel change");

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Thu Feb  9 21:20:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Feb 2023 21:20:51 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v14]
In-Reply-To: <PwPlV_SYqbhZ4gFkXgLfQi7HZeJVYsPvuWcsiWMeeGg=.3711aca0-106a-4409-9292-04cc2bf579eb@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <PwPlV_SYqbhZ4gFkXgLfQi7HZeJVYsPvuWcsiWMeeGg=.3711aca0-106a-4409-9292-04cc2bf579eb@github.com>
Message-ID: <NXanVh0kccksWrmPFkyAHNl_pRVElyFcc8tNWdtgkZs=.006ed6ad-9f3a-42db-b87a-c1aed16dbf4c@github.com>

On Wed, 8 Feb 2023 09:46:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updated

I admit I got confused ? by now.

It's been a long discussion.

> My take is current code fix and spec clarification is done to make code/spec wording consistent with **existing** spec whereas this change is to **enhance** the code/spec which I think we should keep it separate from this fix, as this will cause JCK test to be excluded and will cause JCK to update the test and I am not sure how that will pan out, so I suggest to keep the change to minimal to the extent only which is needed for this fix..

Yet the spec change is unnecessary if you change the order of calls as [discussed above](https://github.com/openjdk/jdk/pull/11940#discussion_r1095103200).

Referring to [the same thread](https://github.com/openjdk/jdk/pull/11940#discussion_r1095741184),

> > > It seems the order of sequence is listener->State.STARTED->doInBackground->listener->DONE->done
> > 
> > Yes, but the different order is specified: listener(STARTED) -> doInBackground -> done -> listener(DONE).
> >
> But then it will violate
> 
> https://github.com/openjdk/jdk/blob/810c8a271b4524ae776e2306ef699e04a7d145a2/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293

No, it doesn't violate: the state transitions to `DONE` *after method is finished*.

And I realised [I had addressed it already](https://github.com/openjdk/jdk/pull/11940#discussion_r1095781185).

[Sergey is right](https://github.com/openjdk/jdk/pull/11940#discussion_r1099522374) there is *no contradiction*. It is how it is specified.

?The spec for `DONE` state does not specify when the transition occurs.? It says _after_, which is satisfied in either case: 1) `done` method is called, state transitions to `DONE`; or 2) state transitions to `DONE`, then `done` method is called.

The first case is how it was implemented before this fix. The second case is how it is implemented at this very moment in the this fix.


If you change the order of these two calls

https://github.com/openjdk/jdk/blob/76b02ea3a8add954705d6df7f91f5896d141b02d/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L307-L308

you'll bring back the code to case 1 which aligns with the current specification.

If you do it, Sergey's concern [in this comment](https://github.com/openjdk/jdk/pull/11940#discussion_r1099522374) *will be resolved*. (For convenience: ?Above we discussed that it is possible to see a difference if the listener will do some work on EDT, after the fix the listener will not be called last, is that safe to assume it does not break something??)

Even though I don't see it as a problem, it is safer to preserve the specified order. Do you agree?

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

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Thu Feb  9 21:45:42 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 9 Feb 2023 21:45:42 GMT
Subject: RFR: 8301616: Drag & maximize to another monitor places window
 incorrectly (Windows)
In-Reply-To: <gzTV82RQHAdCp0YK2W282OVr-Uu2nvf8k7vjnU1VIvU=.ac954f42-5378-450e-88a7-03b820579673@github.com>
References: <lICCRQ57-Bw-5cga6WXNK7edm552gxJNSjJmxHT1t3w=.a5610856-3c0f-4bce-923e-24d8945ebf57@github.com>
 <WoRGGIbLP6ZeiD3nBLm_Wr64IsVYGi_aHM7GfEDjmRI=.388a4404-1d1d-4614-aa57-29bd6416891e@github.com>
 <Rwig96Joy3bNbOD1c3Pyg2PPnyMPXk40EvDRHHbIgr0=.1de94c5b-2fd7-4251-a040-3a53370adb17@github.com>
 <gzTV82RQHAdCp0YK2W282OVr-Uu2nvf8k7vjnU1VIvU=.ac954f42-5378-450e-88a7-03b820579673@github.com>
Message-ID: <FCMLQPi1rfMO6T22E-B2xdR6VE9QZxeMtYfvTWeQ_Uc=.1e1feebe-b374-45eb-82eb-9767b72c9cf4@github.com>

On Fri, 3 Feb 2023 06:09:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Maximized bounds are treated as absolute virtual screen coordinates, when maximized, window will be reshaped to that specific bounds no matter what monitor it is currently on. That is, when dragging to fullscreen from monitor 1 to 2 while maximized bound are in 1st monitor, it will just jump back and maximize there.
>> Also when maximized bounds are set, window looks awful on Win11 with caption looking wider than client area, but that's another topic.
>> So I found that my fix breaks maximized bounds logic - window jumps somewhere outside the monitor.
>> I guess we can apply this `AwtWindow::CheckWindowDPIChange()` jump for maximized windows, but only for those components which are overriden by maximized bounds (not `Integer.MAX_VALUE`).
>
>> I guess we can apply this AwtWindow::CheckWindowDPIChange() jump for maximized windows, but only for those components which are overriden by maximized bounds (not Integer.MAX_VALUE).
> 
> Do you mean apply "CheckWindowDPIChange" to all windows, except maximized in full screen(Integer.MAX_VALUE)? It sounds good, I guess it is not possible to do that in Windows 10. So that change should not break something.
> 
> I wonder what is the order of events the Windows send to the application, at what moment do we get the maximization/zoom property - after the drag to the second screen or before?

To be clear: window will be maximized if you drag it near the top of the monitor and release there.
So you drag the window, cross the monitor border, all DPI-related stuff gets updated, you drag it to the top of the second screen, release the button, it maximizes.
My fix works for me because window is maximized before trying to fit its bounds in `CheckWindowDPIChange()`, here are some last messages from my test:


`WM_WINDOWPOSCHANGING` - here we see IsZoomed=true for the first time
`WM_GETMINMAXINFO`
`WM_NCCALCSIZE`
`WM_NCPAINT`
`WM_ERASEBKGND`
`WM_WINDOWPOSCHANGED`
`WM_MOVE`
`WM_SIZE`
`WM_EXITSIZEMOVE` - here we call `CheckWindowDPIChange()`

However [it is reported](https://youtrack.jetbrains.com/issue/JBR-5238/Drag-to-fullscreen#focus=Comments-27-6834787.0-0) that this fix doesn't work when dragging maximized window to maximized on another monitor.
I have no idea what's the difference, because when you start dragging maximized window, it's restored right then and the final behavior shouldn't be any different from dragging non-maximized one, but maybe I'm missing something.

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

PR: https://git.openjdk.org/jdk/pull/12367


From kizune at openjdk.org  Thu Feb  9 23:32:57 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 9 Feb 2023 23:32:57 GMT
Subject: [jdk20] RFR: 8299077: [REDO] JDK-4512626 Non-editable JTextArea
 provides no visual indication of keyboard focus [v2]
In-Reply-To: <5OTRR04Dy1WnIX-P1xGwjmLRrGlCQphGPjaj5DyUUls=.ba98ddff-d99f-454d-99e0-767d912eba7c@github.com>
References: <Y5n9LN3yc9gOj5Rhh9sqF21P94sflmxoRFnF5xEZi1E=.b74b87cf-d2f8-45d1-befb-e5294af2a534@github.com>
 <9nwTzXDoTgHiSd9hcmzyy0zhvvPj7U2VbsV4h5olsQ4=.fa045e9b-7309-42d0-91a9-875c34de5316@github.com>
 <x2ilcjEu2--mEt3EuOa3_RxFpAa4jZWHoDn9mUQlTcI=.7760a448-0062-4516-a6fc-1e2664f2dab3@github.com>
 <5OTRR04Dy1WnIX-P1xGwjmLRrGlCQphGPjaj5DyUUls=.ba98ddff-d99f-454d-99e0-767d912eba7c@github.com>
Message-ID: <sn83v9v-NiM5RmS_VwolT6CuI0uK-DiiVEDN05yZbmk=.abb8728d-c443-4f59-846c-0eaa6eb5c7ef@github.com>

On Thu, 9 Feb 2023 19:42:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/DefaultCaret.java line 373:
>> 
>>> 371:     // --- FocusListener methods --------------------------
>>> 372: 
>>> 373:     /**
>> 
>> I guess everybody noticed the specification of this method.
>>>This is implemented to set the caret to visible if the component is editable.
>> 
>> That should be updated? And overall it seems the whole behavior change required CSR.
>
> ping

The documented behaviour does not change so no CSR is required. Documentation does not specify what happens when component is not editable it only mentions what this method does about the editable component. Amending the documentation on the other hand would require the CSR.

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

PR: https://git.openjdk.org/jdk20/pull/68


From psadhukhan at openjdk.org  Fri Feb 10 11:46:22 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 11:46:22 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v15]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

 - Fix and test updated
 - Fix and test updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/c5892188..22ff1676

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=13-14

  Stats: 22 lines in 2 files changed: 6 ins; 3 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 11:47:51 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 11:47:51 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v5]
In-Reply-To: <9Du5nigecJsxFxb-ZOJoPYdxWHtf3VV2zgYyTqgTfkA=.33d41c28-d54e-4e6c-9ace-f2686625a38f@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <57-FqOLxWg4kYTkdif8qua-zX9szU-9HYN7ghdA1cYs=.0627bcd0-d72b-4d24-b677-e1366f89971e@github.com>
 <9Du5nigecJsxFxb-ZOJoPYdxWHtf3VV2zgYyTqgTfkA=.33d41c28-d54e-4e6c-9ace-f2686625a38f@github.com>
Message-ID: <JXTFHqe_X4jmGZn5P6NUYdEtocZRLLSCkveD6JMlLNI=.ac523050-127a-446b-ae83-6b2c6c923399@github.com>

On Thu, 9 Feb 2023 20:45:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test
>
> test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 69:
> 
>> 67:                     Font curFont = fc.getFont();
>> 68:                     System.out.println("current font " + curFont);
>> 69:                     if (curFont != null && !curFont.equals(origFont)) {
> 
> Is it valid that `currFont` is `null`?
> 
> Do we expect that `origFont.equals(curFont)` returns `true`? And I assume `origFont` shouldn't be `null` either. So the condition could be simplified to
> 
> Suggestion:
> 
>                     if (!origFont.equals(curFont)) {

In few cases, origFont is null. I am not sure if it's a bug or not but this issue is about L&F transition does not reset so I only checked current font should be same as original font irrespective of it being null or not.

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

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Fri Feb 10 11:52:50 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 11:52:50 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v15]
In-Reply-To: <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
Message-ID: <GpmRRjjzwzxreluhMGKjxakqyjYBb_uCPHacB1fm1qw=.c083ee74-8987-4db5-b820-8f0b57652242@github.com>

On Fri, 10 Feb 2023 11:46:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix and test updated
>  - Fix and test updated

> I admit I got confused ? by now.
> 
> It's been a long discussion.
> 
> > My take is current code fix and spec clarification is done to make code/spec wording consistent with **existing** spec whereas this change is to **enhance** the code/spec which I think we should keep it separate from this fix, as this will cause JCK test to be excluded and will cause JCK to update the test and I am not sure how that will pan out, so I suggest to keep the change to minimal to the extent only which is needed for this fix..
> 
> Yet the spec change is unnecessary if you change the order of calls as [discussed above](https://github.com/openjdk/jdk/pull/11940#discussion_r1095103200).
> 
> Referring to [the same thread](https://github.com/openjdk/jdk/pull/11940#discussion_r1095741184),
> 
> > > > It seems the order of sequence is listener->State.STARTED->doInBackground->listener->DONE->done
> > > 
> > > 
> > > Yes, but the different order is specified: listener(STARTED) -> doInBackground -> done -> listener(DONE).
> > 
> > 
> > But then it will violate
> > https://github.com/openjdk/jdk/blob/810c8a271b4524ae776e2306ef699e04a7d145a2/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L288-L293
> 
> No, it doesn't violate: the state transitions to `DONE` _after method is finished_.
> 
> And I realised [I had addressed it already](https://github.com/openjdk/jdk/pull/11940#discussion_r1095781185).
> 
> [Sergey is right](https://github.com/openjdk/jdk/pull/11940#discussion_r1099522374) there is _no contradiction_. It is how it is specified.
> 
> ?The spec for `DONE` state does not specify when the transition occurs.? It says _after_, which is satisfied in either case: 1) `done` method is called, state transitions to `DONE`; or 2) state transitions to `DONE`, then `done` method is called.
> 
> The first case is how it was implemented before this fix. The second case is how it is implemented at this very moment in the this fix.
> 
> If you change the order of these two calls
> 
> https://github.com/openjdk/jdk/blob/76b02ea3a8add954705d6df7f91f5896d141b02d/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L307-L308
> 
> you'll bring back the code to case 1 which aligns with the current specification.
> 
> If you do it, Sergey's concern [in this comment](https://github.com/openjdk/jdk/pull/11940#discussion_r1099522374) _will be resolved_. (For convenience: ?Above we discussed that it is possible to see a difference if the listener will do some work on EDT, after the fix the listener will not be called last, is that safe to assume it does not break something??)
> 
> Even though I don't see it as a problem, it is safer to preserve the specified order. Do you agree?

Yes, I see..I have updated the fix and test.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb 10 14:25:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 14:25:36 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v15]
In-Reply-To: <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
Message-ID: <_36XGNJ8wvHTG_BFKWBohrAP_bTmpCWh5Efuk8SRJog=.e9ffd6c2-01d3-48d6-8ea7-edc2c21632b0@github.com>

On Fri, 10 Feb 2023 11:46:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix and test updated
>  - Fix and test updated

The changes look good except for the minor comments.

The updated fix doesn't require the CSR.

Please update the copyright year.

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 313:

> 311:                 };
> 312: 
> 313:         future = new FutureTask<T>(callable);

Suggestion:

       future = new FutureTask<T>(callable);

An extra space breaks the correct indentation.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 43:

> 41:     private static final int WAIT_TIME = 200;
> 42:     private static final long CLEANUP_TIME = 1000;
> 43:     private static final CountDownLatch doneLatch = new CountDownLatch(1);

Suggestion:

    private static final int WAIT_TIME = 200;
    private static final long CLEANUP_TIME = 1000;

    private static final AtomicBoolean doInBackgroundStarted = new AtomicBoolean(false);
    private static final AtomicBoolean doInBackgroundFinished = new AtomicBoolean(false);
    private static final CountDownLatch doneLatch = new CountDownLatch(1);


Separate the real constants from the objects which track the state. The flags should also be marked `final`.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 57:

> 55:                     System.out.println("Got interrupted!");
> 56:                 }
> 57:                 try {

Maybe add a blank line between the two try-catch blocks?

And before `return`-statement?

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 73:

> 71:                 if (!doInBackgroundFinished.get()) {
> 72:                     throw new RuntimeException("done called before " +
> 73:                                              " doInBackground is finished");

Suggestion:

                    throw new RuntimeException("done called before " +
                                               "doInBackground is finished");


Add two spaces before the quote and to align it to the one on the line above; remove one space after the quote so that the error message doesn't have two consecutive spaces.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 99:

> 97:                                "PropertyChangeListeners called with " +
> 98:                                "state STARTED before doInBackground is finished");
> 99:                     }

I think one condition is enough. I propose moving the state to be the first condition.


                    if (worker.getState() == SwingWorker.StateValue.STARTED
                        && (doInBackgroundStarted.get()
                            || doInBackgroundFinished.get())) {

We start with *the state* and ensure both `doInBackgroundStarted` and `doInBackgroundFinished` are `false`.

Yes, the error message can't be very specific in this case.

---

Java Code Style suggests binary operators should be wrapped to the next line rather than left on the previous line. I do prefer this style because it highlights *it is a continuation line* rather than a new statement.

I know it isn't followed consistently though. Nor do we have an updated code style guide in the clientlibs that we adhere when writing new code.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 100:

> 98:                                "state STARTED before doInBackground is finished");
> 99:                     }
> 100:                     // After the doInBackground method is finished

Adding a blank line between the conditions would visually separate them.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 104:

> 102:                     // property change to StateValue.DONE
> 103:                     if (doInBackgroundFinished.get() &&
> 104:                             worker.getState() != SwingWorker.StateValue.DONE) {

The condition here should take both flags into account. Again, I propose moving the state condition to be the first one.


                    if (worker.getState() != SwingWorker.StateValue.DONE
                        && doInBackgroundFinished.get()) {

We may also check that `doInBackgroundStarted` is `true`.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 128:

> 126:                            " getState " + worker.getState());
> 127:         if (doInBackgroundFinished.get() &&
> 128:               worker.getState() != SwingWorker.StateValue.DONE) {

Suggestion:

        if (doInBackgroundFinished.get() &&
                worker.getState() != SwingWorker.StateValue.DONE) {

If you follow the style of double indentation on continuation lines, two more spaces should be added.

Consider moving the `&&` operator to the continuation line.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 130:

> 128:               worker.getState() != SwingWorker.StateValue.DONE) {
> 129:             throw new RuntimeException("doInBackground is finished " +
> 130:                                        " but State is not DONE");

Suggestion:

                                       "but the State is not DONE");

Two consecutive spaces in an error message are redundant, one is enough.

The article seems missing?

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb 10 14:34:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 14:34:54 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v15]
In-Reply-To: <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
Message-ID: <qal0QPs4mMQepxTb16re9ThCPQuxP5dD7aZP4-4eg8k=.7ec55a72-50ad-4069-9d6c-1a746ef4e635@github.com>

On Fri, 10 Feb 2023 11:46:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix and test updated
>  - Fix and test updated

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 29:

> 27:  *           before the 'doInBackground' is finished
> 28:  * @run main TestDoneBeforeDoInBackground
> 29:  */

May I ask you to move the jtreg tags to the class declaration, please? When the file is opened in the IDE, they're not collapsed (together with the license block above) and easily accessible.

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 14:49:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 14:49:24 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v16]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <lbU64UJOCMF2tuDIL6cE_Unh0q0jurU_IzThJD8FhFE=.70887aba-efce-4508-8d68-417f0a115a88@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  test updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/22ff1676..f5cc5859

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=14-15

  Stats: 20 lines in 1 file changed: 7 ins; 2 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 14:51:54 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 14:51:54 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v15]
In-Reply-To: <qal0QPs4mMQepxTb16re9ThCPQuxP5dD7aZP4-4eg8k=.7ec55a72-50ad-4069-9d6c-1a746ef4e635@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
 <qal0QPs4mMQepxTb16re9ThCPQuxP5dD7aZP4-4eg8k=.7ec55a72-50ad-4069-9d6c-1a746ef4e635@github.com>
Message-ID: <AVEpFlS3keCapt07qIL48BqkHwrZS2HkMYhHNARidq0=.c732fe07-02f4-4c56-99ee-905da68e118d@github.com>

On Fri, 10 Feb 2023 14:31:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix and test updated
>>  - Fix and test updated
>
> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 29:
> 
>> 27:  *           before the 'doInBackground' is finished
>> 28:  * @run main TestDoneBeforeDoInBackground
>> 29:  */
> 
> May I ask you to move the jtreg tags to the class declaration, please? When the file is opened in the IDE, they're not collapsed (together with the license block above) and easily accessible.

Not sure on this..it seems it is same for other tests also..

> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 130:
> 
>> 128:               worker.getState() != SwingWorker.StateValue.DONE) {
>> 129:             throw new RuntimeException("doInBackground is finished " +
>> 130:                                        " but State is not DONE");
> 
> Suggestion:
> 
>                                        "but the State is not DONE");
> 
> Two consecutive spaces in an error message are redundant, one is enough.
> 
> The article seems missing?

Modified except condition kept separate for distinct failure message

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 15:02:22 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 15:02:22 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v17]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <gxVSi2Rv7rVnZVjvT26EV-DywRIZpsVkbqGkAp51R7o=.3630b279-89b3-4bb6-ad8c-aac88f554a6b@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Space rectify

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/f5cc5859..6776db17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=15-16

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb 10 15:15:57 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 15:15:57 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v17]
In-Reply-To: <gxVSi2Rv7rVnZVjvT26EV-DywRIZpsVkbqGkAp51R7o=.3630b279-89b3-4bb6-ad8c-aac88f554a6b@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gxVSi2Rv7rVnZVjvT26EV-DywRIZpsVkbqGkAp51R7o=.3630b279-89b3-4bb6-ad8c-aac88f554a6b@github.com>
Message-ID: <SfvjxQU3RBiuD5gDi1Y9UkD4d2_625P08oO6DOEt9Z4=.b6523f1b-cba9-4b91-ae6e-7e23efe68449@github.com>

On Fri, 10 Feb 2023 15:02:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Space rectify

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 90:

> 88:                     // property change to StateValue.STARTED
> 89:                     if (doInBackgroundFinished.get()
> 90:                         && worker.getState() == SwingWorker.StateValue.STARTED) {

Suggestion:

                    if (doInBackgroundStarted.get()
                        && worker.getState() == SwingWorker.StateValue.STARTED) {

Align the condition to the error message.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 99:

> 97:                     // before doInBackground started running
> 98:                     if (doInBackgroundStarted.get()
> 99:                         && worker.getState() == SwingWorker.StateValue.STARTED) {

Suggestion:

                    if (doInBackgroundFinished.get()
                        && worker.getState() == SwingWorker.StateValue.STARTED) {

Align the condition to the error message.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 109:

> 107:                     // property change to StateValue.DONE
> 108:                     if (worker.getState() != SwingWorker.StateValue.DONE
> 109:                           && doInBackgroundFinished.get()) {

Suggestion:

                    if (worker.getState() != SwingWorker.StateValue.DONE
                        && doInBackgroundFinished.get()) {

This should also use four-space indentation on the continuation line for consistency with other cases.

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 135:

> 133:             && doInBackgroundFinished.get()) {
> 134:               throw new RuntimeException("doInBackground is finished " +
> 135:                                          "but State is not DONE");

Suggestion:

        if (worker.getState() != SwingWorker.StateValue.DONE
            && doInBackgroundFinished.get()) {
            throw new RuntimeException("doInBackground is finished " +
                                       "but State is not DONE");

Throw shouldn't be indented by additional two spaces.

With the `&&` at the start of the line, it is rather clear where condition ends. Additionally, `throw` cannot be part of the condition.

It's a catch with `if` statement because its condition is always indented by four spaces. If required, a blank line could be added in the body of `if` to separate the condition visually; continuation line could use 8-space indentation.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb 10 15:20:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 15:20:54 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v15]
In-Reply-To: <AVEpFlS3keCapt07qIL48BqkHwrZS2HkMYhHNARidq0=.c732fe07-02f4-4c56-99ee-905da68e118d@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <m3q9ZSK99zIdo75cztXWvn6fw-Ufb6aQPiKZRZiQd0k=.a66b94d6-5b5b-4c61-954e-27121bdeac53@github.com>
 <qal0QPs4mMQepxTb16re9ThCPQuxP5dD7aZP4-4eg8k=.7ec55a72-50ad-4069-9d6c-1a746ef4e635@github.com>
 <AVEpFlS3keCapt07qIL48BqkHwrZS2HkMYhHNARidq0=.c732fe07-02f4-4c56-99ee-905da68e118d@github.com>
Message-ID: <qWJqFtZUKBgm_uhXqmqQ1SCURi-zNRx6FmUEfmhbxcU=.e979afb6-916a-45e3-9bd6-243aac52d27a@github.com>

On Fri, 10 Feb 2023 14:49:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 29:
>> 
>>> 27:  *           before the 'doInBackground' is finished
>>> 28:  * @run main TestDoneBeforeDoInBackground
>>> 29:  */
>> 
>> May I ask you to move the jtreg tags to the class declaration, please? When the file is opened in the IDE, they're not collapsed (together with the license block above) and easily accessible.
>
> Not sure on this..it seems it is same for other tests also..

The majority of old tests have jtreg tags above imports. I find it very inconvenient.

Some newer tests have the jtreg tags before the class declaration.

jtreg accepts either variant.

When I review code, I always ask for this change because the jtreg tags are somewhat important and having them visible is just more convenient. The `@summary` tag provides the info similar to what one expects to find in a javadoc.

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

PR: https://git.openjdk.org/jdk/pull/11940


From aivanov at openjdk.org  Fri Feb 10 15:26:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 15:26:51 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v5]
In-Reply-To: <JXTFHqe_X4jmGZn5P6NUYdEtocZRLLSCkveD6JMlLNI=.ac523050-127a-446b-ae83-6b2c6c923399@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <57-FqOLxWg4kYTkdif8qua-zX9szU-9HYN7ghdA1cYs=.0627bcd0-d72b-4d24-b677-e1366f89971e@github.com>
 <9Du5nigecJsxFxb-ZOJoPYdxWHtf3VV2zgYyTqgTfkA=.33d41c28-d54e-4e6c-9ace-f2686625a38f@github.com>
 <JXTFHqe_X4jmGZn5P6NUYdEtocZRLLSCkveD6JMlLNI=.ac523050-127a-446b-ae83-6b2c6c923399@github.com>
Message-ID: <KEJs723CNniym-a0xdWgNAt7lsoaOc9HKWsKAEl0Ha0=.c5a7efee-f440-4509-b868-c5b0aa34dbfb@github.com>

On Fri, 10 Feb 2023 11:44:35 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 69:
>> 
>>> 67:                     Font curFont = fc.getFont();
>>> 68:                     System.out.println("current font " + curFont);
>>> 69:                     if (curFont != null && !curFont.equals(origFont)) {
>> 
>> Is it valid that `currFont` is `null`?
>> 
>> Do we expect that `origFont.equals(curFont)` returns `true`? And I assume `origFont` shouldn't be `null` either. So the condition could be simplified to
>> 
>> Suggestion:
>> 
>>                     if (!origFont.equals(curFont)) {
>
> In few cases, origFont is null. I am not sure if it's a bug or not but this issue is about L&F transition does not reset so I only checked current font should be same as original font irrespective of it being null or not.

Okay. In such a case, the null-check is required either way.

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

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Fri Feb 10 15:31:28 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 15:31:28 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v18]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <YspN9NelIM1leG3Vc-6_Rei5nTKz2i0abgWPPLJCzH0=.125f258f-56e6-4a49-86e2-165a1bf32a08@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Test alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/6776db17..b2a13025

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=16-17

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 15:31:31 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 15:31:31 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v17]
In-Reply-To: <gxVSi2Rv7rVnZVjvT26EV-DywRIZpsVkbqGkAp51R7o=.3630b279-89b3-4bb6-ad8c-aac88f554a6b@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gxVSi2Rv7rVnZVjvT26EV-DywRIZpsVkbqGkAp51R7o=.3630b279-89b3-4bb6-ad8c-aac88f554a6b@github.com>
Message-ID: <xTr72_cm-xqvVcwKLCa1MuPu9pNCVmXVwtX5O5Rdqy8=.0aabc01c-34fe-42b1-ab95-44cb6bd84ee1@github.com>

On Fri, 10 Feb 2023 15:02:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Space rectify

I have tried alignment to the extent possible..I am not sure if it's required to be so finicky about it :-)

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 16:00:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 16:00:56 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v6]
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <WU9wGFREIlFj5e5qKYRWDoON25XQpkhF-UCPNek80Ho=.69b6af7f-7365-4b7a-9816-a9ace18479fb@github.com>

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

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

  Add both null check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12180/files
  - new: https://git.openjdk.org/jdk/pull/12180/files/dbeb36dc..d4713ff2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Fri Feb 10 16:11:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 16:11:49 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v6]
In-Reply-To: <WU9wGFREIlFj5e5qKYRWDoON25XQpkhF-UCPNek80Ho=.69b6af7f-7365-4b7a-9816-a9ace18479fb@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <WU9wGFREIlFj5e5qKYRWDoON25XQpkhF-UCPNek80Ho=.69b6af7f-7365-4b7a-9816-a9ace18479fb@github.com>
Message-ID: <KWKPuQfzBEMYKI_vCc7A6BoB8tvkYcnowxeixsgEB04=.44d45ae0-4182-46fc-b1dd-359113575001@github.com>

On Fri, 10 Feb 2023 16:00:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add both null check

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 70:

> 68:                     System.out.println("current font " + curFont);
> 69:                     if ((curFont != null && !curFont.equals(origFont)) ||
> 70:                         (origFont != null && !origFont.equals(curFont))) {

The newly added condition is redundant because `origFont.equals(curFont) == curFont.equals(origFont)`. (It's possible `equals` returns different values but it violates its contract then.)

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Fri Feb 10 16:22:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 16:22:52 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v17]
In-Reply-To: <xTr72_cm-xqvVcwKLCa1MuPu9pNCVmXVwtX5O5Rdqy8=.0aabc01c-34fe-42b1-ab95-44cb6bd84ee1@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gxVSi2Rv7rVnZVjvT26EV-DywRIZpsVkbqGkAp51R7o=.3630b279-89b3-4bb6-ad8c-aac88f554a6b@github.com>
 <xTr72_cm-xqvVcwKLCa1MuPu9pNCVmXVwtX5O5Rdqy8=.0aabc01c-34fe-42b1-ab95-44cb6bd84ee1@github.com>
Message-ID: <RI_bWm0oUBweUG4mgWe2Qe0atpX45IEPKdJ2xU7q408=.97e42513-0093-412d-b386-7abd5eb271e1@github.com>

On Fri, 10 Feb 2023 15:26:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I have tried alignment to the extent possible..

Not to the extent possible if it's different from the commonly used style.

> I am not sure if it's required to be so finicky about it :-)

It's probably not. However, the code which uses consistent style in the entire project is easier to read, it looks as if it was written by a single person even though it was actually written by a large team of different people. Otherwise, it's like a text with typos, you're still able to comprehend it but you stumble on each occurrence of one.

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 16:46:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 16:46:24 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v19]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <Y8xgQIVHL-ec24u6M_5nJyfYX9FvzbHGXrqbR_gLD8c=.92118617-9764-4335-aeb7-a763fbc14757@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Test alignment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/b2a13025..d1c95410

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=17-18

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

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Fri Feb 10 17:00:48 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Feb 2023 17:00:48 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v6]
In-Reply-To: <KWKPuQfzBEMYKI_vCc7A6BoB8tvkYcnowxeixsgEB04=.44d45ae0-4182-46fc-b1dd-359113575001@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <WU9wGFREIlFj5e5qKYRWDoON25XQpkhF-UCPNek80Ho=.69b6af7f-7365-4b7a-9816-a9ace18479fb@github.com>
 <KWKPuQfzBEMYKI_vCc7A6BoB8tvkYcnowxeixsgEB04=.44d45ae0-4182-46fc-b1dd-359113575001@github.com>
Message-ID: <IK4JKmSXyb4VXQhhv0sMd06bbrSyPGJfqVkHbTLnvBY=.91ec2b98-d435-43a1-bdcd-53aae2e98f99@github.com>

On Fri, 10 Feb 2023 16:08:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add both null check
>
> test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 70:
> 
>> 68:                     System.out.println("current font " + curFont);
>> 69:                     if ((curFont != null && !curFont.equals(origFont)) ||
>> 70:                         (origFont != null && !origFont.equals(curFont))) {
> 
> The newly added condition is redundant because `origFont.equals(curFont) == curFont.equals(origFont)`. (It's possible `equals` returns different values but it violates its contract then.)

I dont think it's redundant..There's a || check in between

If `curFont `is not null and `origFont `is null, then 1st condition `curFont != null && !curFont.equals(origFont)` is satisfied and it will throw exception

If `origFont `is not null and `curFont `is null, then 1st condition `curFont != null && !curFont.equals(origFont)` is not satisfied and 2nd condition `origFont != null && !origFont.equals(curFont)` is satisfied and it will throw exception. If we remove origFont.equals(curFont) check, it will not check the fix..

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Fri Feb 10 17:12:24 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Feb 2023 17:12:24 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v6]
In-Reply-To: <IK4JKmSXyb4VXQhhv0sMd06bbrSyPGJfqVkHbTLnvBY=.91ec2b98-d435-43a1-bdcd-53aae2e98f99@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <WU9wGFREIlFj5e5qKYRWDoON25XQpkhF-UCPNek80Ho=.69b6af7f-7365-4b7a-9816-a9ace18479fb@github.com>
 <KWKPuQfzBEMYKI_vCc7A6BoB8tvkYcnowxeixsgEB04=.44d45ae0-4182-46fc-b1dd-359113575001@github.com>
 <IK4JKmSXyb4VXQhhv0sMd06bbrSyPGJfqVkHbTLnvBY=.91ec2b98-d435-43a1-bdcd-53aae2e98f99@github.com>
Message-ID: <c3m691EeKrMJjLUC9WBTchHkJN01_L2c43O416Oa93Q=.d28ae942-5f8b-4139-8373-9a3f7e180713@github.com>

On Fri, 10 Feb 2023 16:58:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 70:
>> 
>>> 68:                     System.out.println("current font " + curFont);
>>> 69:                     if ((curFont != null && !curFont.equals(origFont)) ||
>>> 70:                         (origFont != null && !origFont.equals(curFont))) {
>> 
>> The newly added condition is redundant because `origFont.equals(curFont) == curFont.equals(origFont)`. (It's possible `equals` returns different values but it violates its contract then.)
>
> I dont think it's redundant..There's a || check in between
> 
> If `curFont `is not null and `origFont `is null, then 1st condition `curFont != null && !curFont.equals(origFont)` is satisfied and it will throw exception
> 
> If `origFont `is not null and `curFont `is null, then 1st condition `curFont != null && !curFont.equals(origFont)` is not satisfied and 2nd condition `origFont != null && !origFont.equals(curFont)` is satisfied and it will throw exception. If we remove origFont.equals(curFont) check, it will not check the fix..

`curFont != origFont && (curFont != null && !curFont.equals(origFont))`

The first part catches the case where both are null.

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

PR: https://git.openjdk.org/jdk/pull/12180


From duke at openjdk.org  Fri Feb 10 21:21:51 2023
From: duke at openjdk.org (SWinxy)
Date: Fri, 10 Feb 2023 21:21:51 GMT
Subject: RFR: 8302120: Prefer ArrayList to LinkedList in AggregatePainter
In-Reply-To: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
References: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
Message-ID: <WYRUdxKnFzVniFyHhf5orGqmXfSbvQITI1O92oZuj1I=.a9846038-e992-41fe-8ba6-2bd999fec3df@github.com>

On Fri, 27 Jan 2023 13:26:28 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/12254


From serb at openjdk.org  Sat Feb 11 00:24:28 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 11 Feb 2023 00:24:28 GMT
Subject: RFR: 8302120: Prefer ArrayList to LinkedList in AggregatePainter
In-Reply-To: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
References: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
Message-ID: <0gf7d_rHgmcOD8OnI4_JlFsUrnJWPpuPHnf6MqGnQLY=.f74f6609-8c62-47ea-8eb3-2ee706164f75@github.com>

On Fri, 27 Jan 2023 13:26:28 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12254


From aturbanov at openjdk.org  Sat Feb 11 11:16:07 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 11 Feb 2023 11:16:07 GMT
Subject: RFR: 8302268: Prefer ArrayList to LinkedList in XEmbeddedFramePeer
Message-ID: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>

There is only add/iterator/indexOf calls on this list. No removes from the head or something like this. ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

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

Commit messages:
 - [PATCH] Prefer ArrayList to LinkedList in XEmbeddedFramePeer

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

PR: https://git.openjdk.org/jdk/pull/12486


From serb at openjdk.org  Sat Feb 11 11:16:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 11 Feb 2023 11:16:07 GMT
Subject: RFR: 8302268: Prefer ArrayList to LinkedList in XEmbeddedFramePeer
In-Reply-To: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
References: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
Message-ID: <l0TyIdEs0wzhrmxAfW3M7wu9ZbzHILY3Dyn9gQ7i78M=.836ad89a-8428-4114-91d1-1458f679fb17@github.com>

On Thu, 9 Feb 2023 09:51:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator/indexOf calls on this list. No removes from the head or something like this. ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

Looks fine.

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

PR: https://git.openjdk.org/jdk/pull/12486


From aivanov at openjdk.org  Sat Feb 11 16:09:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Sat, 11 Feb 2023 16:09:34 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v17]
In-Reply-To: <RI_bWm0oUBweUG4mgWe2Qe0atpX45IEPKdJ2xU7q408=.97e42513-0093-412d-b386-7abd5eb271e1@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <gxVSi2Rv7rVnZVjvT26EV-DywRIZpsVkbqGkAp51R7o=.3630b279-89b3-4bb6-ad8c-aac88f554a6b@github.com>
 <xTr72_cm-xqvVcwKLCa1MuPu9pNCVmXVwtX5O5Rdqy8=.0aabc01c-34fe-42b1-ab95-44cb6bd84ee1@github.com>
 <RI_bWm0oUBweUG4mgWe2Qe0atpX45IEPKdJ2xU7q408=.97e42513-0093-412d-b386-7abd5eb271e1@github.com>
Message-ID: <qZHDVJg5d0mlxlO3IQyMQarSBP7J4Ffvd-JTe_FlbG4=.e5e6c458-54e0-45bb-8007-71b2a71ab76f@github.com>

On Fri, 10 Feb 2023 16:19:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I have tried alignment to the extent possible..
> 
> Not to the extent possible if it's different from the commonly used style.
> 
> > I am not sure if it's required to be so finicky about it :-)
> 
> It's probably not.

In addition to that, in the cases I have provided suggestions to fix the indentation which can be applied with a single click.

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

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Sat Feb 11 18:24:21 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 11 Feb 2023 18:24:21 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
Message-ID: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>

ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.

There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.

This is not a big change, but it is useful for those working with ImageIO.

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

Commit messages:
 - Implements AutoCloseable

Changes: https://git.openjdk.org/jdk/pull/12098/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302281
  Stats: 20 lines in 3 files changed: 14 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12098.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12098/head:pull/12098

PR: https://git.openjdk.org/jdk/pull/12098


From duke at openjdk.org  Sat Feb 11 20:24:28 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 11 Feb 2023 20:24:28 GMT
Subject: RFR: 8299592: Fix and reenable warnings in java.desktop native
 code compilation [v2]
In-Reply-To: <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
References: <9l01eRt230npHNblN6c0Q7mpAdzi4QQqucogoF8IstY=.6aee2928-1e6d-4279-be6b-75e94ac5f5b7@github.com>
 <E7Uak5J0FFV1ik7CMYbs3Z87N_15lGVRcs5ZTsBtWhE=.1f760cef-d01b-446f-b6bc-4f7248ddccf0@github.com>
Message-ID: <JH29DUmCrvwSzt4adhyWMk4NTW_kDBGW0SGHx6brpbA=.0ee91f53-5c8f-49e7-a469-549338ee6091@github.com>

On Fri, 20 Jan 2023 12:01:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this patch that fixes and re-enables a few warnings in libawt compilation.
>> 
>> Verified that debug and release builds finish successfully on Win, Mac and Linux. Also verified that client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge remote-tracking branch 'origin' into awt-warning-cleanup
>  - Copyright
>  - snprintf
>  - cl analyze
>  - Fix non-debug warning
>  - Restore suppressions
>  - Fix warnings
>  - WIP: reenable awt warnings
>  - Fix warnings

These changes look fine to me as well. Built and ran a couple dozen tests. `D3DBlitLoops.cpp` looks to have had a hidden bug that is now fixed with this patch. Granted, I am not to be trusted with native code.

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

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/11841


From duke at openjdk.org  Sat Feb 11 22:07:25 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 11 Feb 2023 22:07:25 GMT
Subject: RFR: 8302268: Prefer ArrayList to LinkedList in XEmbeddedFramePeer
In-Reply-To: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
References: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
Message-ID: <fEGi5zQg9YRdkn6TZmUFBDgKUDYvWujeZeaOz7kJRZU=.51139277-7769-48a7-a869-a31831969bc5@github.com>

On Thu, 9 Feb 2023 09:51:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator/indexOf calls on this list. No removes from the head or something like this. ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

As usual I prefer `List<>` as the type.

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

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

PR: https://git.openjdk.org/jdk/pull/12486


From duke at openjdk.org  Sun Feb 12 01:31:34 2023
From: duke at openjdk.org (Glavo)
Date: Sun, 12 Feb 2023 01:31:34 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
In-Reply-To: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
Message-ID: <mTv1-0d3it3LTAU9nbPHuNN3nwqVKX5knYzZaGzLG6E=.bab493fb-aba9-4f61-937d-a0b31ee5a2fc@github.com>

On Thu, 19 Jan 2023 18:41:08 GMT, Markus KARG <duke at openjdk.org> wrote:

> ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.
> 
> There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.
> 
> This is not a big change, but it is useful for those working with ImageIO.

src/java.desktop/share/classes/javax/imageio/ImageReader.java line 2883:

> 2881:      * @implNote The default implementation of this method invokes {@link #dispose()}.
> 2882:      */
> 2883:     public void close() {

(Not a reviewer) I think we need to add the `@since` tag to javadoc.

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

PR: https://git.openjdk.org/jdk/pull/12098


From duke at openjdk.org  Sun Feb 12 08:22:30 2023
From: duke at openjdk.org (ScientificWare)
Date: Sun, 12 Feb 2023 08:22:30 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v27]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <ube8htvdBHse0fUUzcpVlkAJCUYkVfdzMjRy94xhapg=.2748ec0c-3485-410b-9946-cb238fb08fc0@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)

ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into scientificware-patch-002-CSS-add_missing_named_color
   
   # Conflicts:
   #	src/java.desktop/share/classes/javax/swing/text/html/CSS.java
   #	src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
 - CSS.java
   - Updates copyright date to 2023.
   - Adds the missing color names defined by :
     CSS Color Module Level 4
     W3C Candidate Recommendation Snapshot, 5 July 2022
     [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
     - Adds relative imports.
     - Replaces, if ... then ... else statements with a Map called "colorNamed".
   
   StyleSheet.java ;
   - Updates copyright date to 2023.
   - Updates stringToColor specifications to integrate a reference to CSS Color Module 4 for color names and hexadecimal notation.
   
   MissingColorNames.java :
   - Cr?ation d'un test pour les nouveaux noms de couleurs ajout?s.
 - MissingColorNames.java :
   Moves jtreg tags to the class declaration. Comment with tags isn't collapsed when viewed in an IDE if it's placed before the class declaration.
 - JDK8292276MissingColorNamesInCSS.java -> MissingColorNames.java :
   - Changement de nom.
   - D?placement vers un autre dossier.
   - Simplification d'une description.
   - Ajout d'espaces manquants.
   - Correction de l'alignement d'un d?limiteur de commentaire.
   
   CSS.java :
   - Changement de nom pour la variable colorNamed.
   - Ajout du modificateur final ? la variable ColorNames.
   - Uniformisation de l'utilisation de la variable strlc.
   - renvoi direct de la couleur trouv?e si elle existe.
 - Probl?me de configuration de KWrite.
   Qui rajoutait un retour ligne ? la fin de chaque fichier.
 - CSS.java
   - Corrige une grossi?re erreur de code :
   Modifie l'emplacement de la mise en minuscules pour le placer juste apr?s les cas pour lequel cela n'a pas d'importance et surtout apr?s avoir envisager le cas null.
     Sinon ce pouvait engendrer un NPE.
   - Modifie la d?claration des couleurs opaques. En choisissant la d?claration avec trois entiers.
   
   JDS8292276MissingColorNamesInCSS.java :
   - Ajout du cas null.
   - Ajout du test sur le
 - Erreur de nom.
   Un caract?re de retour ? la ligne s'est immiscer dans le nom du dossier.
 - This commit modifies stringToColor method
       - by correcting orange definition,
       - by adding 132 missing color names,
         - including transparent keyword
         - but excluding currentcolor keyword.
       - by treating RGB and Hex notations in insensitive case mode.
   This commit modifies stringToColor method which has no modifier, so only usages are limited to :
       - its Class.
       - The inner Class ColorValue also without modifier uses it through the method to return the Color Object
       - its Package.
       - stringToColor is also used by javax.swing.text.html.StyleSheet stringToColor method to publicly return the Color Object.
       - conclusion : since Color Object is publicly exposed, one can't change method behavior. This preventing to return a constant Color excepted for the existing String.isEmpty argument.
   Refactoring resolving color value and align it with 5.7. Resolving Values Values) will be treated in another PR. Extends JDK-8149631 rgb(...) CSS color values are not parsed properly.
 - Test case for JDK-8292276
   
   Adds a jtreg test case that fails before JDK-8292276 patch and passes after.
   Test the Cyan color name.
   Cyan is the missing color name that originates the PR JDK8292276 : Missing Color NamesIn CSS.
   Cyan name, as most color names Colors defined in CSS Color Module Level 4, is not referenced in CSS.java.
   This test fails, if getAttribute doesn't return a cyan Color Object.
   When a color name is missing getAttribute returns a black Color Object.
 - Adds to CSS.java, the missing color names defined by :
   CSS Color Module Level 4
   W3C Candidate Recommendation Snapshot, 5 July 2022
   [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
   - Updates, Copyright year.
   - Adds relative imports.
   - Replaces, if ... then ... else statements with a Map called "colorNamed".
     Code is more readable and easy to maintain.
     After tests, TreeMap seems slower than Map. Results are available at scientificware#12 (comment).
   
   Warning : The Previous JDK CSS Orange Color is different from CSS Color Recommendation.

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

Changes: https://git.openjdk.org/jdk/pull/9825/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=26
  Stats: 275 lines in 4 files changed: 215 ins; 0 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Sun Feb 12 08:59:42 2023
From: duke at openjdk.org (ScientificWare)
Date: Sun, 12 Feb 2023 08:59:42 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v28]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)

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

  Delete configure
  
  Delete configure from the pull request.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/1386bcc9..db0244d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=26-27

  Stats: 35 lines in 1 file changed: 0 ins; 35 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9825.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9825/head:pull/9825

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Sun Feb 12 09:41:47 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 12 Feb 2023 09:41:47 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v2]
In-Reply-To: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
Message-ID: <y3J9iKiUgSyeLZGbDKZzHTPq3MfshKmIMuwrx3lhU04=.0a3e8f31-aa3b-46cd-84c3-27f47f321220@github.com>

> ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.
> 
> There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.
> 
> This is not a big change, but it is useful for those working with ImageIO.

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

  Added @since

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12098/files
  - new: https://git.openjdk.org/jdk/pull/12098/files/9e4d7add..7991ea30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12098


From duke at openjdk.org  Sun Feb 12 09:41:47 2023
From: duke at openjdk.org (Markus KARG)
Date: Sun, 12 Feb 2023 09:41:47 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v2]
In-Reply-To: <mTv1-0d3it3LTAU9nbPHuNN3nwqVKX5knYzZaGzLG6E=.bab493fb-aba9-4f61-937d-a0b31ee5a2fc@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
 <mTv1-0d3it3LTAU9nbPHuNN3nwqVKX5knYzZaGzLG6E=.bab493fb-aba9-4f61-937d-a0b31ee5a2fc@github.com>
Message-ID: <HYEvA4-U5oWBZ4JBLFbu3yVdsODAB7-0KhChUo5Pm5k=.6a41dd43-137d-41d5-9a20-ffc1af399dc2@github.com>

On Sun, 12 Feb 2023 01:28:40 GMT, Glavo <duke at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @since
>
> src/java.desktop/share/classes/javax/imageio/ImageReader.java line 2883:
> 
>> 2881:      * @implNote The default implementation of this method invokes {@link #dispose()}.
>> 2882:      */
>> 2883:     public void close() {
> 
> (Not a reviewer) I think we need to add the `@since` tag to javadoc.

Good catch! I added `@since` in https://github.com/openjdk/jdk/pull/12098/commits/7991ea30f18a7e98f4f37cae40c8f86dba6ea7c9.

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

PR: https://git.openjdk.org/jdk/pull/12098


From tr at openjdk.org  Mon Feb 13 04:39:27 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 13 Feb 2023 04:39:27 GMT
Subject: RFR: 8299713: Test
 javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor
In-Reply-To: <jCkdfVb8ZEVUlr6xDdIqYSPDo3cFJKwtOzETYdgwqQU=.42068408-50e6-4d56-8167-f76b44242db7@github.com>
References: <jCkdfVb8ZEVUlr6xDdIqYSPDo3cFJKwtOzETYdgwqQU=.42068408-50e6-4d56-8167-f76b44242db7@github.com>
Message-ID: <AZ0XA3GusdbFHgSnMePTD5zjD9eLmq46R5tw7tgVwFc=.dd670232-f2db-452d-9451-f19c615d038e@github.com>

On Wed, 25 Jan 2023 08:32:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue seems to be very old, very intermittent bug which is not reproducible in repeated test run,
> so added some stability fixes like accessing swing components in EDT, delay, frame dispose and take a screenshot during fail.
> Multiple runs on CI platforms is ok.

Marked as reviewed by tr (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12181


From tr at openjdk.org  Mon Feb 13 04:58:28 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 13 Feb 2023 04:58:28 GMT
Subject: RFR: 8299713: Test
 javax/swing/JTableHeader/6889007/bug6889007.java failed: Wrong type of cursor
In-Reply-To: <eao5G7uMPnITKZIwmQT-OQ8SkDxskstZ5DbyCwX1JX8=.82f76996-a95f-4859-9355-78b42c56cfd7@github.com>
References: <jCkdfVb8ZEVUlr6xDdIqYSPDo3cFJKwtOzETYdgwqQU=.42068408-50e6-4d56-8167-f76b44242db7@github.com>
 <eao5G7uMPnITKZIwmQT-OQ8SkDxskstZ5DbyCwX1JX8=.82f76996-a95f-4859-9355-78b42c56cfd7@github.com>
Message-ID: <c35NEmXVggmqN0M9QkVKOJyjwzvGleGBG6L4CV7_cp4=.f4e6a0ac-d6da-41b2-ab76-e0aa565f7e5d@github.com>

On Fri, 27 Jan 2023 11:02:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> @prsadhuk Trying to run the test in **ubuntu** system, it ended with time out error. Test passed in **windows** system.

@kumarabhi006 I'm not getting any such error in _ubuntu_. Fix is working for me in windows and ubuntu.

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

PR: https://git.openjdk.org/jdk/pull/12181


From psadhukhan at openjdk.org  Mon Feb 13 09:02:39 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 13 Feb 2023 09:02:39 GMT
Subject: Integrated: 6513512: MetalLookAndFeel.initClassDefaults does not
 install an entry for MetalMenuBarUI
In-Reply-To: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
References: <OOiwmyYuBF20PPIuo5zjeRJfaLVVdPgC1o4Z1S4K5Cs=.f36821e2-33d4-4524-a2ee-a1d3e781a3e0@github.com>
Message-ID: <t5bEbTLb1LRY7t7Cx6FnhkeRsQY2mnX8sCr69KdSqng=.5c359121-32e0-493d-898c-713059bd75b5@github.com>

On Tue, 13 Dec 2022 09:56:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Spec for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L247)
> says:
> "...MetalLookAndFeel registers an entry for each of the classes
> in the package javax.swing.plaf.metal that are named MetalXXXUI.
> The string XXX is one of Swing's uiClassIDs. For the uiClassIDs
> that do not have a class in metal, the corresponding class in
> javax.swing.plaf.basic is used. For example, metal does not
> have a class named "MetalColorChooserUI", as such,
> javax.swing.plaf.basic.BasicColorChooserUI is used".
> 
> There is class MetalMenuBarUI, but the method populates given defaults table with the value
> "javax.swing.plaf.basic.BasicMenuBarUI".
> 
> Added entry for MetalMenuBarUI..
> CI tests including JCK tests are ok.

This pull request has now been integrated.

Changeset: 0458d382
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0458d3825c0b6ba215a87143ad472acdcba59f40
Stats:     3 lines in 2 files changed: 1 ins; 2 del; 0 mod

6513512: MetalLookAndFeel.initClassDefaults does not install an entry for MetalMenuBarUI

Reviewed-by: serb, aivanov

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

PR: https://git.openjdk.org/jdk/pull/11646


From psadhukhan at openjdk.org  Mon Feb 13 09:19:05 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 13 Feb 2023 09:19:05 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v7]
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <EIljz7KjLqy_6gOv8SSDbGIrXGKFbS1OpGXSWzAKdVs=.9987542b-3dcd-4c68-9a1f-8cc5e8cf9fd2@github.com>

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12180/files
  - new: https://git.openjdk.org/jdk/pull/12180/files/d4713ff2..61e47df4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12180&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Mon Feb 13 09:22:35 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 13 Feb 2023 09:22:35 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v6]
In-Reply-To: <c3m691EeKrMJjLUC9WBTchHkJN01_L2c43O416Oa93Q=.d28ae942-5f8b-4139-8373-9a3f7e180713@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <WU9wGFREIlFj5e5qKYRWDoON25XQpkhF-UCPNek80Ho=.69b6af7f-7365-4b7a-9816-a9ace18479fb@github.com>
 <KWKPuQfzBEMYKI_vCc7A6BoB8tvkYcnowxeixsgEB04=.44d45ae0-4182-46fc-b1dd-359113575001@github.com>
 <IK4JKmSXyb4VXQhhv0sMd06bbrSyPGJfqVkHbTLnvBY=.91ec2b98-d435-43a1-bdcd-53aae2e98f99@github.com>
 <c3m691EeKrMJjLUC9WBTchHkJN01_L2c43O416Oa93Q=.d28ae942-5f8b-4139-8373-9a3f7e180713@github.com>
Message-ID: <5oLdz4O9NiDYxxQa3T4R76fP8WnwZJODWrHGybe6cgU=.d063f62d-7c75-45cb-a9b0-a29b2eb97168@github.com>

On Fri, 10 Feb 2023 17:08:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I dont think it's redundant..There's a || check in between
>> 
>> If `curFont `is not null and `origFont `is null, then 1st condition `curFont != null && !curFont.equals(origFont)` is satisfied and it will throw exception
>> 
>> If `origFont `is not null and `curFont `is null, then 1st condition `curFont != null && !curFont.equals(origFont)` is not satisfied and 2nd condition `origFont != null && !origFont.equals(curFont)` is satisfied and it will throw exception. If we remove origFont.equals(curFont) check, it will not check the fix..
>
> `curFont != origFont && (curFont != null && !curFont.equals(origFont))`
> 
> The first part catches the case where both are null.

ok..modified but I guess mine was not "incorrect" either..

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

PR: https://git.openjdk.org/jdk/pull/12180


From psadhukhan at openjdk.org  Mon Feb 13 09:24:38 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 13 Feb 2023 09:24:38 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v19]
In-Reply-To: <Y8xgQIVHL-ec24u6M_5nJyfYX9FvzbHGXrqbR_gLD8c=.92118617-9764-4335-aeb7-a763fbc14757@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <Y8xgQIVHL-ec24u6M_5nJyfYX9FvzbHGXrqbR_gLD8c=.92118617-9764-4335-aeb7-a763fbc14757@github.com>
Message-ID: <aXvXnBHy_aEvavxeHuTCIPs7-EqpS8o3BfP5otppPlE=.9340d638-9dc0-46f1-861e-4562cbd37453@github.com>

On Fri, 10 Feb 2023 16:46:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test alignment

I guess current iteration of the PR takes care of the alignment being suggested..

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

PR: https://git.openjdk.org/jdk/pull/11940


From dnguyen at openjdk.org  Mon Feb 13 17:12:23 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 13 Feb 2023 17:12:23 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS system
 LaF
Message-ID: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>

Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.

Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.

Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.

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

Commit messages:
 - Fix whitespace error
 - Add ending line in test
 - Update AquaButton conditional. Add automated test for Aqua

Changes: https://git.openjdk.org/jdk/pull/12520/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302173
  Stats: 174 lines in 2 files changed: 162 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12520.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12520/head:pull/12520

PR: https://git.openjdk.org/jdk/pull/12520


From prr at openjdk.org  Mon Feb 13 21:03:30 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 13 Feb 2023 21:03:30 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v2]
In-Reply-To: <y3J9iKiUgSyeLZGbDKZzHTPq3MfshKmIMuwrx3lhU04=.0a3e8f31-aa3b-46cd-84c3-27f47f321220@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
 <y3J9iKiUgSyeLZGbDKZzHTPq3MfshKmIMuwrx3lhU04=.0a3e8f31-aa3b-46cd-84c3-27f47f321220@github.com>
Message-ID: <EhUSjILkcO9jHedQiYal2wv1IJahK3DsKfnbBpOGD1g=.12354da0-ded9-49fa-bd14-f8fbf64f828f@github.com>

On Sun, 12 Feb 2023 09:41:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.
>> 
>> There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.
>> 
>> This is not a big change, but it is useful for those working with ImageIO.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @since

PR rejected

I am not sure about this.
1) The ImageReader & ImageWriter don't seem natural candidates
2) I would have thought Closeable over AutoClosable
3) And ImageInputStream and ImageOutputstream classes  ALREADY implement Closable which extends AutoCloseable (!)

So it seems odd .. and pointless .. and perhaps wrong .. 
So no to this request. Please withdraw and close as will not fix.

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

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12098


From prr at openjdk.org  Mon Feb 13 21:06:28 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 13 Feb 2023 21:06:28 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v2]
In-Reply-To: <y3J9iKiUgSyeLZGbDKZzHTPq3MfshKmIMuwrx3lhU04=.0a3e8f31-aa3b-46cd-84c3-27f47f321220@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
 <y3J9iKiUgSyeLZGbDKZzHTPq3MfshKmIMuwrx3lhU04=.0a3e8f31-aa3b-46cd-84c3-27f47f321220@github.com>
Message-ID: <H2-rtfxP-wKnL-klTE-an6aS5AOV6Ai2eeGMtqWRlbo=.cdc79af2-00b0-4b07-be5a-c69807c743ad@github.com>

On Sun, 12 Feb 2023 09:41:47 GMT, Markus KARG <duke at openjdk.org> wrote:

>> ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.
>> 
>> There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.
>> 
>> This is not a big change, but it is useful for those working with ImageIO.
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added @since

oh, and in future discuss things like this on the list and get agreement BEFORE posting a PR.
See https://openjdk.org/groups/client-libs/
"Proposing a change" where this is discussed.

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

PR: https://git.openjdk.org/jdk/pull/12098


From honkar at openjdk.org  Tue Feb 14 02:31:52 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 14 Feb 2023 02:31:52 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF
In-Reply-To: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
Message-ID: <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>

On Sat, 11 Feb 2023 00:23:05 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
> 
> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
> 
> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.

Changes requested by honkar (Committer).

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 78:

> 76: import com.apple.laf.AquaUtils.RecyclableSingleton;
> 77: import com.apple.laf.AquaUtils.RecyclableSingletonFromDefaultConstructor;
> 78: import sun.swing.SwingUtilities2;

Copyright year needs to be updated for AquaButtonUI.

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 343:

> 341:         final String text;
> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
> 343:         if (v != null && ((AbstractButton) c).getText().contains("<img ")) {

You might want to test a combination of HTML image + icon added to JButton, to make sure the fix works correctly under different combinations.

Suggestion: Does having `((AbstractButton) c).getIcon() == null` make it more robust than checking for html tag patterns ?

test/jdk/javax/swing/JButton/HtmlButtonWithTextAndIcon.java line 50:

> 48: import static java.awt.image.BufferedImage.TYPE_INT_ARGB;
> 49: 
> 50: public class HtmlButtonWithTextAndIcon {

Would it be a good idea to combine `HtmlButtonWithTextAndIcon`  & `HtmlButtonImageTest` into one comprehensive test, since they are similar? This would also make sure that all the cases related to JButton's HTML ImageView are available at one place.

test/jdk/javax/swing/JButton/HtmlButtonWithTextAndIcon.java line 57:

> 55:     private static final int BUTTON_WIDTH = 59;
> 56:     private static final int BUTTON_HEIGHT = 28;
> 57:     private static final int ICON_WIDTH = 16;

To make testing easier with different icon & button sizes, it is better to have button width and height as a factor of icon size (1.5 times or greater) as mentioned here [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854).

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

PR: https://git.openjdk.org/jdk/pull/12520


From aivanov at openjdk.org  Tue Feb 14 11:42:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 14 Feb 2023 11:42:51 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v7]
In-Reply-To: <EIljz7KjLqy_6gOv8SSDbGIrXGKFbS1OpGXSWzAKdVs=.9987542b-3dcd-4c68-9a1f-8cc5e8cf9fd2@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <EIljz7KjLqy_6gOv8SSDbGIrXGKFbS1OpGXSWzAKdVs=.9987542b-3dcd-4c68-9a1f-8cc5e8cf9fd2@github.com>
Message-ID: <qJ__uqXPO9MJT5scxAy5O2WNQuSdsxSyshORS9RRcV4=.74d9d69d-985c-4991-b858-6669c6cfe326@github.com>

On Mon, 13 Feb 2023 09:19:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 76:

> 74:                 }
> 75:                 System.out.println("");
> 76:                 System.out.println("");

Suggestion:

                System.out.println();
                System.out.println();

The empty string parameter is redundant.

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Tue Feb 14 11:45:43 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 14 Feb 2023 11:45:43 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v6]
In-Reply-To: <5oLdz4O9NiDYxxQa3T4R76fP8WnwZJODWrHGybe6cgU=.d063f62d-7c75-45cb-a9b0-a29b2eb97168@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <WU9wGFREIlFj5e5qKYRWDoON25XQpkhF-UCPNek80Ho=.69b6af7f-7365-4b7a-9816-a9ace18479fb@github.com>
 <KWKPuQfzBEMYKI_vCc7A6BoB8tvkYcnowxeixsgEB04=.44d45ae0-4182-46fc-b1dd-359113575001@github.com>
 <IK4JKmSXyb4VXQhhv0sMd06bbrSyPGJfqVkHbTLnvBY=.91ec2b98-d435-43a1-bdcd-53aae2e98f99@github.com>
 <c3m691EeKrMJjLUC9WBTchHkJN01_L2c43O416Oa93Q=.d28ae942-5f8b-4139-8373-9a3f7e180713@github.com>
 <5oLdz4O9NiDYxxQa3T4R76fP8WnwZJODWrHGybe6cgU=.d063f62d-7c75-45cb-a9b0-a29b2eb97168@github.com>
Message-ID: <S2eh3TcoY2ISoa5qWANNkY9ZzfQfDog5M8vxydgnFhg=.371dbf8d-d38c-434c-9595-db02796b7e91@github.com>

On Mon, 13 Feb 2023 09:19:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> ok..modified but I guess mine was not "incorrect" either..

No, it was not wrong.

I believe this way is clearer though: if `curFont == origFont`, `equals` is bound to return `true`, so you can just avoid calling `equals` twice and make the condition shorter.

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

PR: https://git.openjdk.org/jdk/pull/12180


From aivanov at openjdk.org  Tue Feb 14 12:05:56 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 14 Feb 2023 12:05:56 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v19]
In-Reply-To: <Y8xgQIVHL-ec24u6M_5nJyfYX9FvzbHGXrqbR_gLD8c=.92118617-9764-4335-aeb7-a763fbc14757@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <Y8xgQIVHL-ec24u6M_5nJyfYX9FvzbHGXrqbR_gLD8c=.92118617-9764-4335-aeb7-a763fbc14757@github.com>
Message-ID: <7Py8h9c_6iANmAHFNUtBMX6Yp2CeTV8NwG0DPvavXtk=.28aff466-e60f-4d37-95a0-614b351fcf6f@github.com>

On Fri, 10 Feb 2023 16:46:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test alignment

Should `evt.getNewValue()` be used to identify the new value of the state property?

The test does not fail if I change the order of the lines in the `finally` block that reverses the order in which the `done` method is called and listeners are notified. I expected it to fail. Isn't it the reason why `PropertyChangeListener` was added?

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 103:

> 101:                               "PropertyChangeListeners called with " +
> 102:                                "state STARTED before doInBackground is finished");
> 103:                     }

The comments, conditions and error messages do not match.

In the first case, it should be `doInBackgroundStarted` instead of `doInBackgroundFinished`; in the second ? `doInBackgroundFinished` correspondingly.

Or the error messages should be swapped.

Did you mean anything else?

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

Changes requested by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11940


From mickleness at gmail.com  Tue Feb 14 18:24:59 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Tue, 14 Feb 2023 18:24:59 +0000
Subject: Quit Behavior (specifically for Mac)
Message-ID: <emf06f6e6f-95bd-4e07-8c03-4513a29319b6@9b873760.com>

A colleague and I are confused about how our Swing desktop app on Mac 
should exit.

(Please let me know if there?s a better forum to address this question 
to?)

In QuitHandler the documentation reads:

"Implementors must call either QuitResponse.cancelQuit() 
<https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/java/awt/desktop/QuitResponse.html#cancelQuit()>, 
QuitResponse.performQuit() 
<https://docs.oracle.com/en/java/javase/19/docs/api/java.desktop/java/awt/desktop/QuitResponse.html#performQuit()>, 
or ensure the application terminates.?

? but what if our application processes the request to terminate but 
does not ?ensure the application terminates??

For ex: suppose we initiate a series of user dialogs (?do you want to 
save your changes??), but the user clicks ?Cancel? to indicate they 
don?t want to proceed. So we are handling/consuming the quit request 
responsibly, but technically we haven?t done any of the 3 actions we 
?must? do.

Is this acceptable? (and if so: should we have a ticket to reword the 
QuitHandler documentation?)

Or if it is not acceptable: what bad side-effects should we know to test 
for?

Regards,
  - Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230214/f19254b1/attachment.htm>

From dnguyen at openjdk.org  Tue Feb 14 19:11:20 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 19:11:20 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v6]
In-Reply-To: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
Message-ID: <FM44N03SBOGGiCnGDwH9s4pXVpReUYRQaR--J8BXFN4=.19fb3f9c-7597-4048-a90b-e74676df9cf3@github.com>

> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
> 
> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
> 
> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
> 
> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.

Damon Nguyen has updated the pull request incrementally with four additional commits since the last revision:

 - Remove extra bufferedImage
 - Fix crlf
 - Add automated test. Cycle thru all LAF
 - Add testing for other LAFs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12390/files
  - new: https://git.openjdk.org/jdk/pull/12390/files/cdbc9a89..71e7d54d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12390&range=04-05

  Stats: 304 lines in 2 files changed: 176 ins; 128 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12390.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12390/head:pull/12390

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Tue Feb 14 19:11:20 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 19:11:20 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v4]
In-Reply-To: <nKYC66BXLf5yaHW0ahZc_k2d6N6ipCnDrCJ4_L9438g=.ab1b824d-a94d-4b96-8e80-efa449e1fe5c@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <oLNHzae5efTvN8IglXFXM_nTjavRTQN3vGGlynfEwKA=.116e846f-2f17-4707-b914-1548681b5d9a@github.com>
 <XJ8UxDulBuYZHKdhLXLYjhGXN9XAO22uUoVhPC-ZaPs=.2258979b-6401-4d4e-9370-d29a2b51d659@github.com>
 <NndterQASTmoDb-A5Wj2ZDRfH6GtOaF4SFhAFg21wVM=.c48203de-5abe-4d0e-a000-b9fa6c7b8684@github.com>
 <hj9vlRUZYV8FN6qbc_djvyz8hKeGQ8gdRJDU2lTtie4=.e5fd9f91-8e5a-4404-8235-f3caa950ede2@github.com>
 <CgpsraezLr8k2n9_8eFpNfeYusF-zd2QjyhUkQZFOx0=.cd471c4c-a8f3-437c-9ffc-255d4147a649@github.com>
 <iWiJxvUJol3N3f5iAm0yDFmIMQAUsiE4lChFvlxlkPA=.e85c4cef-3f5c-48c9-a704-aea3f54a2442@github.com>
 <nKYC66BXLf5yaHW0ahZc_k2d6N6ipCnDrCJ4_L9438g=.ab1b824d-a94d-4b96-8e80-efa449e1fe5c@github.com>
Message-ID: <bKVr9BKA5oyG5nUdQ4osi0omNn3wDexmluYKMe34RO0=.d63788cd-2a5e-448f-a0d6-2f64c7b5ca1f@github.com>

On Thu, 9 Feb 2023 03:21:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > I created an automated test, but for some L&F's (such as Nimbus), an enabled vs disabled ComboBox differs in more than just the text color. The background, border, and button color may change as well
> > > 
> > > 
> > > Then can we not compare the comboBox without DLCR with comboBox with DLCR when both are disabled...both should be same as per your screenshot
> > 
> > 
> > A comboBox with DLCR is slightly smaller than one without DLCR (138x25 vs 140x25). If I force the same dimensions with setSize, the RGB values are slightly off. If these comboBoxes are supposed to exactly match in dimensions, they currently don't, and this is due to what would be a separate bug if so.
> 
> maybe you can try to compare the mid scanline rather than the whole rectangle

Replaced the original test with an automated version using a mid scanline. I can't scan across the whole midline because of the width difference, so I adjusted the testing method slightly to accommodate for this.

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

PR: https://git.openjdk.org/jdk/pull/12390


From dnguyen at openjdk.org  Tue Feb 14 19:34:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 19:34:46 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF
In-Reply-To: <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
Message-ID: <IVGg3B_4ZUDEx3SZwTD-Va4hen9s8l-XdoDqYrzWhgk=.ae592364-f7ed-4f6f-aa0e-8dc2dd110221@github.com>

On Tue, 14 Feb 2023 02:19:15 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
>> 
>> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
>> 
>> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 343:
> 
>> 341:         final String text;
>> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
>> 343:         if (v != null && ((AbstractButton) c).getText().contains("<img ")) {
> 
> You might want to test a combination of HTML image + icon added to JButton, to make sure the fix works correctly under different combinations.
> 
> Suggestion: Does having `((AbstractButton) c).getIcon() == null` make it more robust than checking for html tag patterns ?

The icon isn't the HTML image like in the similar test `HtmlButtonImageTest`. This time the HTML is the text and the icon is simply a separate image. This is the cause of the issue. The importance will be if the HTML contents is actually an image or just HTML text.

> test/jdk/javax/swing/JButton/HtmlButtonWithTextAndIcon.java line 57:
> 
>> 55:     private static final int BUTTON_WIDTH = 59;
>> 56:     private static final int BUTTON_HEIGHT = 28;
>> 57:     private static final int ICON_WIDTH = 16;
> 
> To make testing easier with different icon & button sizes, it is better to have button width and height as a factor of icon size (1.5 times or greater) as mentioned here [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854).

I had the same thought, but decided to use these values for width and height due to wanting to match the provided test in the issue. This was to best mimic the overlapping displayed in the screenshots, and using these fixed values seems like the best way for me to replicate the overlapping. These are the width & height values of the button in the original test provided so I used the same icon size, text, and button dimensions.

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Tue Feb 14 19:57:41 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 19:57:41 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF
In-Reply-To: <IVGg3B_4ZUDEx3SZwTD-Va4hen9s8l-XdoDqYrzWhgk=.ae592364-f7ed-4f6f-aa0e-8dc2dd110221@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
 <IVGg3B_4ZUDEx3SZwTD-Va4hen9s8l-XdoDqYrzWhgk=.ae592364-f7ed-4f6f-aa0e-8dc2dd110221@github.com>
Message-ID: <y1BIRq3c0jzeTf-GGHkngwtrp9Aq2q9A08l9EuegWFo=.0037eab5-c598-4509-8a3d-a25d4fa47a8c@github.com>

On Tue, 14 Feb 2023 19:31:34 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 343:
>> 
>>> 341:         final String text;
>>> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
>>> 343:         if (v != null && ((AbstractButton) c).getText().contains("<img ")) {
>> 
>> You might want to test a combination of HTML image + icon added to JButton, to make sure the fix works correctly under different combinations.
>> 
>> Suggestion: Does having `((AbstractButton) c).getIcon() == null` make it more robust than checking for html tag patterns ?
>
> The icon isn't the HTML image like in the similar test `HtmlButtonImageTest`. This time the HTML is the text and the icon is simply a separate image. This is the cause of the issue. The importance will be if the HTML contents is actually an image or just HTML text.

Nevermind, I see your point now that I've reread this. Checking for an icon achieves the same effect without having to check for an img pattern as long as one is adjusted. So, I think the icon check is more robust and cleaner. Thanks!

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Tue Feb 14 19:57:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 19:57:46 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF
In-Reply-To: <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
Message-ID: <cJJNYwby3s6J0XeLQgBedCWDOvagpGM1QSpOjs61P-8=.a57c4bed-9ea2-425b-b74b-fd074d19f673@github.com>

On Tue, 14 Feb 2023 02:27:58 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
>> 
>> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
>> 
>> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.
>
> test/jdk/javax/swing/JButton/HtmlButtonWithTextAndIcon.java line 50:
> 
>> 48: import static java.awt.image.BufferedImage.TYPE_INT_ARGB;
>> 49: 
>> 50: public class HtmlButtonWithTextAndIcon {
> 
> Would it be a good idea to combine `HtmlButtonWithTextAndIcon`  & `HtmlButtonImageTest` into one comprehensive test, since they are similar? This would also make sure that all the cases related to JButton's HTML ImageView are available at one place.

I think it's OK from my perspective to have separate tests here because one relates to an icon while the other handles HTML images.

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Tue Feb 14 20:04:10 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 20:04:10 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v2]
In-Reply-To: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
Message-ID: <ZITT3ZgGjC5yToDaZg5R4yEWEoztOfOAq9RgnddLSLw=.c4682780-59ec-450e-ba6e-1cd2737caf1d@github.com>

> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
> 
> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
> 
> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.

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

  Update copyright year. Update conditional

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12520/files
  - new: https://git.openjdk.org/jdk/pull/12520/files/5dd6a9f2..5d08afe5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12520


From honkar at openjdk.org  Tue Feb 14 20:07:43 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 14 Feb 2023 20:07:43 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v2]
In-Reply-To: <y1BIRq3c0jzeTf-GGHkngwtrp9Aq2q9A08l9EuegWFo=.0037eab5-c598-4509-8a3d-a25d4fa47a8c@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
 <IVGg3B_4ZUDEx3SZwTD-Va4hen9s8l-XdoDqYrzWhgk=.ae592364-f7ed-4f6f-aa0e-8dc2dd110221@github.com>
 <y1BIRq3c0jzeTf-GGHkngwtrp9Aq2q9A08l9EuegWFo=.0037eab5-c598-4509-8a3d-a25d4fa47a8c@github.com>
Message-ID: <t67_SVpxOLgZnvR1vKVpXARm4ck46uZ7KeXnOMVE1Ms=.6f958319-9c3c-4ce1-99cf-0977a9a1077c@github.com>

On Tue, 14 Feb 2023 19:54:04 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The icon isn't the HTML image like in the similar test `HtmlButtonImageTest`. This time the HTML is the text and the icon is simply a separate image. This is the cause of the issue. The importance will be if the HTML contents is actually an image or just HTML text.
>
> Nevermind, I see your point now that I've reread this. Checking for an icon achieves the same effect without having to check for an img pattern as long as one is adjusted. So, I think the icon check is more robust and cleaner. Thanks!

@DamonGuy  Additionally, you might need to make sure the conditional and the fix works under different combinations especially when you have an html with `<img>` tag + icon, both added to the button.

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Tue Feb 14 21:14:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 21:14:46 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v2]
In-Reply-To: <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
Message-ID: <T-et7xN5CDf5_JzW9vt1On2rdmRkKByb8a1I6_KLaHE=.d751d6ff-d734-44eb-99cb-afb28ec8d638@github.com>

On Tue, 14 Feb 2023 02:23:16 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year. Update conditional
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 78:
> 
>> 76: import com.apple.laf.AquaUtils.RecyclableSingleton;
>> 77: import com.apple.laf.AquaUtils.RecyclableSingletonFromDefaultConstructor;
>> 78: import sun.swing.SwingUtilities2;
> 
> Copyright year needs to be updated for AquaButtonUI.

Updated

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Tue Feb 14 21:14:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 21:14:46 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v2]
In-Reply-To: <t67_SVpxOLgZnvR1vKVpXARm4ck46uZ7KeXnOMVE1Ms=.6f958319-9c3c-4ce1-99cf-0977a9a1077c@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
 <IVGg3B_4ZUDEx3SZwTD-Va4hen9s8l-XdoDqYrzWhgk=.ae592364-f7ed-4f6f-aa0e-8dc2dd110221@github.com>
 <y1BIRq3c0jzeTf-GGHkngwtrp9Aq2q9A08l9EuegWFo=.0037eab5-c598-4509-8a3d-a25d4fa47a8c@github.com>
 <t67_SVpxOLgZnvR1vKVpXARm4ck46uZ7KeXnOMVE1Ms=.6f958319-9c3c-4ce1-99cf-0977a9a1077c@github.com>
Message-ID: <412axEFZnkuUb0pJ6jdYkcLs5nf-7HrnvI6CK8fMbeo=.41b70c81-5c3a-415c-ac38-2f8b220324c1@github.com>

On Tue, 14 Feb 2023 20:03:20 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Nevermind, I see your point now that I've reread this. Checking for an icon achieves the same effect without having to check for an img pattern as long as one is adjusted. So, I think the icon check is more robust and cleaner. Thanks!
>
> @DamonGuy  Additionally, you might need to make sure the conditional and the fix works under different combinations especially when you have an html with `<img>` tag + icon, both added to the button.

Yes, I tested with these combinations:
Icon with HTML image
<img width="274" alt="Screen Shot 2023-02-14 at 12 30 23 PM" src="https://user-images.githubusercontent.com/96267980/218855067-68186106-77df-4c2b-81d7-2cd24e28f4bb.png">

Icon with HTML text
<img width="270" alt="Screen Shot 2023-02-14 at 1 10 28 PM" src="https://user-images.githubusercontent.com/96267980/218863780-de2293ea-9da6-4db9-9201-4788b7567478.png">

And the `HtmlButtonImageTest` still passes as expected

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

PR: https://git.openjdk.org/jdk/pull/12520


From xuelei at openjdk.org  Tue Feb 14 22:03:30 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 14 Feb 2023 22:03:30 GMT
Subject: RFR: 8302495: update for deprecated sprintf for java.desktop
Message-ID: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>

Hi,

May I have this update reviewed?

The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in java.desktop components.

Thanks,
Xuelei

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

Commit messages:
 - 8302495: update for deprecated sprintf for java.desktop

Changes: https://git.openjdk.org/jdk/pull/12565/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302495
  Stats: 76 lines in 19 files changed: 2 ins; 0 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/12565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12565/head:pull/12565

PR: https://git.openjdk.org/jdk/pull/12565


From honkar at openjdk.org  Tue Feb 14 22:11:42 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 14 Feb 2023 22:11:42 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v2]
In-Reply-To: <412axEFZnkuUb0pJ6jdYkcLs5nf-7HrnvI6CK8fMbeo=.41b70c81-5c3a-415c-ac38-2f8b220324c1@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
 <IVGg3B_4ZUDEx3SZwTD-Va4hen9s8l-XdoDqYrzWhgk=.ae592364-f7ed-4f6f-aa0e-8dc2dd110221@github.com>
 <y1BIRq3c0jzeTf-GGHkngwtrp9Aq2q9A08l9EuegWFo=.0037eab5-c598-4509-8a3d-a25d4fa47a8c@github.com>
 <t67_SVpxOLgZnvR1vKVpXARm4ck46uZ7KeXnOMVE1Ms=.6f958319-9c3c-4ce1-99cf-0977a9a1077c@github.com>
 <412axEFZnkuUb0pJ6jdYkcLs5nf-7HrnvI6CK8fMbeo=.41b70c81-5c3a-415c-ac38-2f8b220324c1@github.com>
Message-ID: <nTmIzAQzhgBHeBncPKoEVPfg3uQRTMUKW40P_uK0zrI=.7132892f-25be-44ea-93aa-5b32cd3dbc43@github.com>

On Tue, 14 Feb 2023 21:11:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> @DamonGuy  Additionally, you might need to make sure the conditional and the fix works under different combinations especially when you have an html with `<img>` tag + icon, both added to the button.
>
> Yes, I tested with these combinations:
> Icon with HTML image
> <img width="274" alt="Screen Shot 2023-02-14 at 12 30 23 PM" src="https://user-images.githubusercontent.com/96267980/218855067-68186106-77df-4c2b-81d7-2cd24e28f4bb.png">
> 
> Icon with HTML text
> <img width="270" alt="Screen Shot 2023-02-14 at 1 10 28 PM" src="https://user-images.githubusercontent.com/96267980/218863780-de2293ea-9da6-4db9-9201-4788b7567478.png">
> 
> And the `HtmlButtonImageTest` still passes as expected

Looks good.

I might have missed it earlier, adding an instanceof check makes it safer before calling getIcon(). What do you think?
`if (v != null && c instanceof AbstractButton && ((AbstractButton) c).getIcon() == null)){`

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Tue Feb 14 23:02:16 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 23:02:16 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v3]
In-Reply-To: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
Message-ID: <Aid3vKSu2kPE3SGY2yvQntUi4cE8fOZmlJ5Y1bVz-Xs=.237ee245-302c-4426-b2b1-46ff7bbdcb46@github.com>

> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
> 
> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
> 
> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.

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

  Add instanceof check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12520/files
  - new: https://git.openjdk.org/jdk/pull/12520/files/5d08afe5..e18a63ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Tue Feb 14 23:02:17 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 14 Feb 2023 23:02:17 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v3]
In-Reply-To: <nTmIzAQzhgBHeBncPKoEVPfg3uQRTMUKW40P_uK0zrI=.7132892f-25be-44ea-93aa-5b32cd3dbc43@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
 <IVGg3B_4ZUDEx3SZwTD-Va4hen9s8l-XdoDqYrzWhgk=.ae592364-f7ed-4f6f-aa0e-8dc2dd110221@github.com>
 <y1BIRq3c0jzeTf-GGHkngwtrp9Aq2q9A08l9EuegWFo=.0037eab5-c598-4509-8a3d-a25d4fa47a8c@github.com>
 <t67_SVpxOLgZnvR1vKVpXARm4ck46uZ7KeXnOMVE1Ms=.6f958319-9c3c-4ce1-99cf-0977a9a1077c@github.com>
 <412axEFZnkuUb0pJ6jdYkcLs5nf-7HrnvI6CK8fMbeo=.41b70c81-5c3a-415c-ac38-2f8b220324c1@github.com>
 <nTmIzAQzhgBHeBncPKoEVPfg3uQRTMUKW40P_uK0zrI=.7132892f-25be-44ea-93aa-5b32cd3dbc43@github.com>
Message-ID: <yDUKLfAx5ZVeKAPwY2G_Yywjm0yPMEN75IWQBwjDStk=.d4026976-8a0f-4de9-b039-0e6852489854@github.com>

On Tue, 14 Feb 2023 22:08:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Yes, I tested with these combinations:
>> Icon with HTML image
>> <img width="274" alt="Screen Shot 2023-02-14 at 12 30 23 PM" src="https://user-images.githubusercontent.com/96267980/218855067-68186106-77df-4c2b-81d7-2cd24e28f4bb.png">
>> 
>> Icon with HTML text
>> <img width="270" alt="Screen Shot 2023-02-14 at 1 10 28 PM" src="https://user-images.githubusercontent.com/96267980/218863780-de2293ea-9da6-4db9-9201-4788b7567478.png">
>> 
>> And the `HtmlButtonImageTest` still passes as expected
>
> Looks good.
> 
> I might have missed it earlier, adding an instanceof check makes it safer before calling getIcon(). What do you think?
> `if (v != null && c instanceof AbstractButton && ((AbstractButton) c).getIcon() == null)){`

Implemented your suggestion. I agree, it's more stable this way.

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

PR: https://git.openjdk.org/jdk/pull/12520


From prr at openjdk.org  Wed Feb 15 02:02:54 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Feb 2023 02:02:54 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <fzTNuZov9bq2-3W1yuLVOz8Q6LkOwCOF8JC2RaVxJv4=.2c652631-54fe-4b89-a65e-408b4afe5c67@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
 <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
 <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>
 <gtF7oKLWghMLLzoiZIt-zi5iCc-SXZNyKZpBOl4oVBc=.30e3cbcd-9f64-4439-96ba-6adc30603985@github.com>
 <4xoGJjdHdkrDjsc77ahROvDdvdXzKd3vlasVT0zH6VU=.b5fa7af5-75b6-40e2-b4e0-b2619c1e3bba@github.com>
 <OJ1NfIgF0JdTDMd4cLyLyY5Cg4a0W0b2AQqIB5Fg-7c=.e4bfcb3d-b277-456e-81bd-2513817d321f@github.com>
 <fzTNuZov9bq2-3W1yuLVOz8Q6LkOwCOF8JC
 2RaVxJv4=.2c652631-54fe-4b89-a65e-408b4afe5c67@github.com>
Message-ID: <Clxj-1eIX9GTmYSaUzJlFZ-n_lp3ujct6Af-ER9jOho=.0142e825-acc7-4943-9c81-d7ef8685d148@github.com>

On Wed, 1 Feb 2023 23:40:08 GMT, Nikita Gubarkov <duke at openjdk.org> wrote:

>> So I restored the original idea.
>> 1. Place Symbol into main font sequences to preceed the Emoji and be able to have exclusion ranges
>> 2. Exclude everything that should be colored by default
>> 3. One more hack in composite mapper - ignore exclude ranges when variation selector is specified
>> 
>> Results:
>> * No selector, default mono: will be handled by Symbol
>> * No selector, default color: skip Symbol because excluded, handle by Emoji
>> * FE0F (color): skip Symbol because it doesn't define mapping for this selector, handle by Emoji
>> * FE0E (mono): skip Symbol & Emoji & remaining fonts because they don't define this selector. No glyph found, so try again without selector, but ignoring exclusion ranges - handle by Symbol
>
> The best idea that came to my mind so far is to insert proxy "emoji" mapper into fallback sequence, which will handle default variations and stuff and then forward calls to real mono/color mapper. And this logic can also be reused in other OSes. What do you think?

If the problem we are trying to solve here is around which code points have a default emoji presentation then I think we can have an internal table based on Unicode 15's emoji-data.txt
The JDK sources include a copy of that in java.base, but I don't propose we access it - just use it to hand build a table of the 1205 default emoji.

If that ISN'T the problem you are trying to solve then you'll need to explain it again.
Also I had a VERY brief exchange about whether java.lang.Character could expose this info to us - built directly from that CLDR data. That may be the longer term solution which might start out as JDK internal API.

Then how to fiddle around multiple fonts to do this is the next question.
I really don't want to have knowledge of the code points a particular font supports
(ie the exclusion ranges) but if we just do a lookup on that table and its a hit, then we can go looking through any fonts with a  COLR table for an emoji glyph. Otherwise no need to do anything. 
We'd need to convince ourselves that it is OK that inserting a VS for emoji=off could make us find a different design from a different font. 
Or we just put the emoji font before the symbol font .. 

And as for what "native apps do", tell me how you tested this.
In my testing on Windows 11 "WordPad aka Write" seems incapable of displaying color emoji.
Notepad can .. but the variation selector is not doing anything.
And I'm not sure what font glyphs come from but I don't see it mattering as long as we do something like the above

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

PR: https://git.openjdk.org/jdk/pull/4798


From psadhukhan at openjdk.org  Wed Feb 15 05:29:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Feb 2023 05:29:11 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v20]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <_tXwtjbxmCbvmI86REtHh76Qy00h3E4Nmtab4kZGiF8=.94369d23-5363-4a99-b4b8-6f1d34db7531@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/d1c95410..ca7f54f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=18-19

  Stats: 17 lines in 1 file changed: 9 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/11940.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11940/head:pull/11940

PR: https://git.openjdk.org/jdk/pull/11940


From psadhukhan at openjdk.org  Wed Feb 15 05:29:13 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Feb 2023 05:29:13 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v19]
In-Reply-To: <7Py8h9c_6iANmAHFNUtBMX6Yp2CeTV8NwG0DPvavXtk=.28aff466-e60f-4d37-95a0-614b351fcf6f@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <Y8xgQIVHL-ec24u6M_5nJyfYX9FvzbHGXrqbR_gLD8c=.92118617-9764-4335-aeb7-a763fbc14757@github.com>
 <7Py8h9c_6iANmAHFNUtBMX6Yp2CeTV8NwG0DPvavXtk=.28aff466-e60f-4d37-95a0-614b351fcf6f@github.com>
Message-ID: <kAQ5gkiX4v3IxdBx8M1Eg-PUuLqN-GzbsjdDIVv-QHQ=.33030698-9518-4610-9859-3d3fe48a50bd@github.com>

On Tue, 14 Feb 2023 11:55:05 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 alignment
>
> test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 103:
> 
>> 101:                               "PropertyChangeListeners called with " +
>> 102:                                "state STARTED before doInBackground is finished");
>> 103:                     }
> 
> The comments, conditions and error messages do not match.
> 
> In the first case, it should be `doInBackgroundStarted` instead of `doInBackgroundFinished`; in the second ? `doInBackgroundFinished` correspondingly.
> 
> Or the error messages should be swapped.
> 
> Did you mean anything else?

Test is updated to test the order

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Wed Feb 15 06:27:44 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 15 Feb 2023 06:27:44 GMT
Subject: RFR: 6753661: JFileChooser font not reset after Look & Feel change
 [v7]
In-Reply-To: <EIljz7KjLqy_6gOv8SSDbGIrXGKFbS1OpGXSWzAKdVs=.9987542b-3dcd-4c68-9a1f-8cc5e8cf9fd2@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
 <EIljz7KjLqy_6gOv8SSDbGIrXGKFbS1OpGXSWzAKdVs=.9987542b-3dcd-4c68-9a1f-8cc5e8cf9fd2@github.com>
Message-ID: <yfd9ju2OfxTP1rHi2HF1rhZTU-67WoBRCHZsFbiNeDM=.32dd9d1a-e5f2-4df1-bbd9-fc105ef0e667@github.com>

On Mon, 13 Feb 2023 09:19:05 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
>> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
>> Fix is made to reset the font if it is set by L&F.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12180


From duke at openjdk.org  Wed Feb 15 08:10:04 2023
From: duke at openjdk.org (duke)
Date: Wed, 15 Feb 2023 08:10:04 GMT
Subject: Withdrawn: 8295707: Create a regression test for JDK-7184401
In-Reply-To: <vIN06D-gVbz3GLi_NQZIQkx57ZyCiCKZCVKqm62g9nw=.ccf472cd-6020-457d-af86-911f6f248cf9@github.com>
References: <vIN06D-gVbz3GLi_NQZIQkx57ZyCiCKZCVKqm62g9nw=.ccf472cd-6020-457d-af86-911f6f248cf9@github.com>
Message-ID: <yDivDuQEIREdZePw3d_eJuh3GWc3e6vmb8UAz65NBh4=.64b3988d-4cb8-4686-9ee1-26d405a0b4e2@github.com>

On Thu, 20 Oct 2022 08:59:20 GMT, Srinivas Mandalika <smandalika at openjdk.org> wrote:

> 8295707: Create a regression test for JDK-7184401
> 
> JDK-7184401 - JDk7u6 : Missing main menu bar in Netbeans after fix for 7162144
> Above bug got introduced due to a fix for [JDK-7162144](https://bugs.openjdk.java.net/browse/JDK-7162144). 
> The issue was observed on the netbeans UI. 
> The test below recreates a standalone test to mimic the failure reported in Netbeans in [JDK-7184401](https://bugs.openjdk.java.net/browse/JDK-7184401) and verifies that it is working as expected after it got fixed via [JDK-7189350](https://bugs.openjdk.java.net/browse/JDK-7189350))
> 
> The Test attempts to reproduce specific behavior of NetBeans at the certain toolbar creation stage. Widgets are created on EDT; Another code posts some events to them on EDT; From another thread some code calls explicitly edt.interrupt().
> Before this got fixed, events from a second code got lost.
> 
> This review is for migrating tests from a closed test suite to open.
> Testing:
> 1.Tested the code on jdk7u6 to reproduce the issue - the UI hangs when run on this build.
> 2. Tested the code on jdk7u361 b01 to validate the fix - the test passed.
> 3.Mach5 Testing(40 times per platform) in macos x64, linux x64 and windows x64 - the .results are clean

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10784


From duke at openjdk.org  Wed Feb 15 10:54:57 2023
From: duke at openjdk.org (Nikita Gubarkov)
Date: Wed, 15 Feb 2023 10:54:57 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v18]
In-Reply-To: <Clxj-1eIX9GTmYSaUzJlFZ-n_lp3ujct6Af-ER9jOho=.0142e825-acc7-4943-9c81-d7ef8685d148@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <REfC20MnodFwslolnG4Fhn1CTbrTu0NG_hBFEKwqfBk=.cb232ff4-d58f-406c-a0f8-7aeae605f61e@github.com>
 <GJB6MMhiXcVW2n9f0CXVSeEWlNb6x3-Get2AcUhDR_U=.cf74c3c2-4ed9-404e-958d-ca8f097b8002@github.com>
 <q4RGGyH8I779ZoqhSZixrQi9AVcGgf1QkVHxw_9vmTU=.836d66db-e987-4a62-be0c-aff965d0c066@github.com>
 <R8J6XCWu6ToNwI_k86_5mI5P8zkCy5SowZTD-UqwFSY=.494b7bcc-8f9a-4d80-a2d3-55d42aa9c8cb@github.com>
 <eFxIiU13Z6ZL8E00DtoFboGdlzkDuxITR89pxN2qM7Q=.fbb56393-7630-44d5-b471-ef0d9fd0ee41@github.com>
 <d6b6nS9ElINnEEMpf3P4xArChksbpnHOiZ9V_CRBJ1A=.2acfdfd0-5cea-4e15-99fd-068752221d9b@github.com>
 <gtF7oKLWghMLLzoiZIt-zi5iCc-SXZNyKZpBOl4oVBc=.30e3cbcd-9f64-4439-96ba-6adc30603985@github.com>
 <4xoGJjdHdkrDjsc77ahROvDdvdXzKd3vlasVT0zH6VU=.b5fa7af5-75b6-40e2-b4e0-b2619c1e3bba@github.com>
 <OJ1NfIgF0JdTDMd4cLyLyY5Cg4a0W0b2AQqIB5Fg-7c=.e4bfcb3d-b277-456e-81bd-2513817d321f@github.com>
 <fzTNuZov9bq2-3W1yuLVOz8Q6LkOwCOF8JC
 2RaVxJv4=.2c652631-54fe-4b89-a65e-408b4afe5c67@github.com>
 <Clxj-1eIX9GTmYSaUzJlFZ-n_lp3ujct6Af-ER9jOho=.0142e825-acc7-4943-9c81-d7ef8685d148@github.com>
Message-ID: <wPlNvBHUTCCoGBo_mYvxwshkKJ0p5yvB1Z0cb4tg1mQ=.1f2d7235-0189-4de8-8b03-bcf846ec2498@github.com>

On Wed, 15 Feb 2023 02:00:19 GMT, Phil Race <prr at openjdk.org> wrote:

>> The best idea that came to my mind so far is to insert proxy "emoji" mapper into fallback sequence, which will handle default variations and stuff and then forward calls to real mono/color mapper. And this logic can also be reused in other OSes. What do you think?
>
> If the problem we are trying to solve here is around which code points have a default emoji presentation then I think we can have an internal table based on Unicode 15's emoji-data.txt
> The JDK sources include a copy of that in java.base, but I don't propose we access it - just use it to hand build a table of the 1205 default emoji.
> 
> If that ISN'T the problem you are trying to solve then you'll need to explain it again.
> Also I had a VERY brief exchange about whether java.lang.Character could expose this info to us - built directly from that CLDR data. That may be the longer term solution which might start out as JDK internal API.
> 
> Then how to fiddle around multiple fonts to do this is the next question.
> I really don't want to have knowledge of the code points a particular font supports
> (ie the exclusion ranges) but if we just do a lookup on that table and its a hit, then we can go looking through any fonts with a  COLR table for an emoji glyph. Otherwise no need to do anything. 
> We'd need to convince ourselves that it is OK that inserting a VS for emoji=off could make us find a different design from a different font. 
> Or we just put the emoji font before the symbol font .. 
> 
> And as for what "native apps do", tell me how you tested this.
> In my testing on Windows 11 "WordPad aka Write" seems incapable of displaying color emoji.
> Notepad can .. but the variation selector is not doing anything.
> And I'm not sure what font glyphs come from but I don't see it mattering as long as we do something like the above

Yes, that's the problem I'm trying to solve - determine default mono/emoji presentation for a code point.
And second part of this problem is how to alter this presentation with variation selectors.
I will try this approach with the lookup table and then we'll discuss this in more details.

Regarding native apps, I tested this on Windows 11 (and Windows 10 when I was implementing this) by copying this string into textfields of different apps:
? ?? ?? ? ?? ??
It's a plain emoji, then with mono selector, then with emoji selector, then repeat with different unicode.
The difference is that "heart" emoji is mono and "fire" is colored by default, so if app correctly handles VS, it should display like this:
M M C C M C

My results:
Notepad - works correctly, including VS. Mono from Symbol and colored from Emoji.
WordPad - uses Symbol (mono) with plain unicode, base (mono) glyphs from Emoji font when VS is present.
Address bar in Explorer - always mono, using base glyphs from Emoji font.
Google Chrome - works correctly, like Notepad if using search field on google.com, always colored when using address bar, preview of this comment shows all colored as well.

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

PR: https://git.openjdk.org/jdk/pull/4798


From duke at openjdk.org  Wed Feb 15 13:13:41 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Wed, 15 Feb 2023 13:13:41 GMT
Subject: RFR: 8302525: Write a test to checks various components sends Events
 while mouse and key operations simultaneously
Message-ID: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>

Main aim of this testcase is to test the behavior of various events under stress.

This testcase verifies the following assertions
a. This TestCase performs various mouse and key operations on components and checks whether all the events are getting triggered
b. properly. It also checks some of the component specific events like item, action wherever necessary.

Testing:
Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

Commit messages:
 - 8302525: Write a test to checks various components sends Events while mouse and key operations simultaneously

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

PR: https://git.openjdk.org/jdk/pull/12571


From jdv at openjdk.org  Wed Feb 15 13:25:44 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 15 Feb 2023 13:25:44 GMT
Subject: RFR: 8302151: BMPImageReader throws an exception reading BMP images
Message-ID: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>

We have check in BMPImageReader, where we verify image data size using BMP file size and bitmap offset value.
But we can't rely on this calculation when we have color palette. Also color palette is necessary in BMP when bits per pixel is less than 16 according to BMP specification(https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header).

Now extra checks are added to not perform this check when we have color palette or bpp is less than 16.

Also when bitsPerPixel was less than 8 it was getting down-casted to 0. So this is also resolved by making this check for >=16bpp and not doing (bitsPerPixel / 8)

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

Commit messages:
 - 8302151: BMPImageReader throws an exception reading BMP images

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

PR: https://git.openjdk.org/jdk/pull/12573


From aivanov at openjdk.org  Wed Feb 15 15:22:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 15 Feb 2023 15:22:14 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v20]
In-Reply-To: <_tXwtjbxmCbvmI86REtHh76Qy00h3E4Nmtab4kZGiF8=.94369d23-5363-4a99-b4b8-6f1d34db7531@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <_tXwtjbxmCbvmI86REtHh76Qy00h3E4Nmtab4kZGiF8=.94369d23-5363-4a99-b4b8-6f1d34db7531@github.com>
Message-ID: <h3CweiDCZu47HPCnHUQSK70lNAYb1ZAPTr8_xFmfXsA=.e7ba102d-27c0-4c10-86f7-c4da9a16f26a@github.com>

On Wed, 15 Feb 2023 05:29:11 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/SwingWorker/TestDoneBeforeDoInBackground.java line 89:

> 87:                 public void propertyChange(PropertyChangeEvent evt) {
> 88:                     System.out.println("doInBackground started: " +
> 89:                                         doInBackgroundStarted.get() +

Suggestion:

                    System.out.println("doInBackgroundStarted: " +
                                        doInBackgroundStarted.get() +

Just for consistency with the following `-Finished` line.

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

PR: https://git.openjdk.org/jdk/pull/11940


From mvs at openjdk.org  Wed Feb 15 17:05:53 2023
From: mvs at openjdk.org (Manukumar V S)
Date: Wed, 15 Feb 2023 17:05:53 GMT
Subject: RFR: 8302525: Write a test to checks various components sends
 Events while mouse and key operations simultaneously
In-Reply-To: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
References: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
Message-ID: <TIl33lniVlM0s9N0eS3rc--f7lpNyRKMDDQeDS-sQNc=.76216a8d-5c6b-4f18-99bc-7c3d4fd3d0d2@github.com>

On Wed, 15 Feb 2023 12:50:42 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> Main aim of this testcase is to test the behavior of various events under stress.
> 
> This testcase verifies the following assertions
> a. This TestCase performs various mouse and key operations on components and checks whether all the events are getting triggered
> b. properly. It also checks some of the component specific events like item, action wherever necessary.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

test/jdk/java/awt/event/StressTest/MouseAndKeyEventStressTest.java line 47:

> 45:  * @key headful
> 46:  * @bug 8302525
> 47:  * @summary Test performs various mouse and key operations to checks events are getting triggered properly.

spelling - 'to check'

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

PR: https://git.openjdk.org/jdk/pull/12571


From serb at openjdk.org  Wed Feb 15 23:23:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 15 Feb 2023 23:23:12 GMT
Subject: RFR: 8302151: BMPImageReader throws an exception reading BMP
 images
In-Reply-To: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
References: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
Message-ID: <8Ct2eSCf6q_6wxerg_QBbEza1AkwwAQJobHQ1Zw34XA=.d40c87c9-9bb3-485d-8a90-82f7b590cb87@github.com>

On Wed, 15 Feb 2023 13:18:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have check in BMPImageReader, where we verify image data size using BMP file size and bitmap offset value.
> But we can't rely on this calculation when we have color palette. Also color palette is necessary in BMP when bits per pixel is less than 16 according to BMP specification(https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header).
> 
> Now extra checks are added to not perform this check when we have color palette or bpp is less than 16.
> 
> Also when bitsPerPixel was less than 8 it was getting down-casted to 0. So this is also resolved by making this check for >=16bpp and not doing (bitsPerPixel / 8)

src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java line 596:

> 594: 
> 595:         if (metadata.compression == BI_RGB &&
> 596:             metadata.paletteSize == 0 &&

Do we validate the "metadata.paletteSize" in all code paths above or it can be substituted to have the wrong value(do we actually trust it)?

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

PR: https://git.openjdk.org/jdk/pull/12573


From psadhukhan at openjdk.org  Thu Feb 16 05:06:29 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Feb 2023 05:06:29 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v6]
In-Reply-To: <FM44N03SBOGGiCnGDwH9s4pXVpReUYRQaR--J8BXFN4=.19fb3f9c-7597-4048-a90b-e74676df9cf3@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <FM44N03SBOGGiCnGDwH9s4pXVpReUYRQaR--J8BXFN4=.19fb3f9c-7597-4048-a90b-e74676df9cf3@github.com>
Message-ID: <wHVt7YvJst3iIXBF865g2iclcjfnx5Yvafk9kWoLUx8=.558f3d0b-dae3-427c-af30-c86f42913079@github.com>

On Tue, 14 Feb 2023 19:11:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove extra bufferedImage
>  - Fix crlf
>  - Add automated test. Cycle thru all LAF
>  - Add testing for other LAFs

Did you try extending DLCR for `SynthComboBoxRenderer `instead of implementing LCR interface?
https://github.com/openjdk/jdk/blob/1480d418e3b7d1f36ace24a043a273fca446eefa/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthComboBoxUI.java#L502

just as it is done here
https://github.com/openjdk/jdk/blob/1480d418e3b7d1f36ace24a043a273fca446eefa/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthListUI.java#L211

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

PR: https://git.openjdk.org/jdk/pull/12390


From psadhukhan at openjdk.org  Thu Feb 16 05:13:16 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Feb 2023 05:13:16 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Test fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/ca7f54f9..22ef8f51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=19-20

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

PR: https://git.openjdk.org/jdk/pull/11940


From mickleness at gmail.com  Thu Feb 16 06:07:44 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Thu, 16 Feb 2023 06:07:44 +0000
Subject: Stage Manager Problems
Message-ID: <em7c1e413a-5764-4ae1-8853-b1cf1b1e97c9@17fbc042.com>

We?re experiencing problems related JFrames while Stage Manager 
<https://www.computerworld.com/article/3667999/what-is-apple-stage-manager-and-how-is-it-used.html> 
is active Mac.

When Stage Manager is active the yellow minimize button on our JFrame?s 
appears to ?minimize? our app. But as far as our Frame is concerned:
1. Frame.getExtendedState() does not indicate we?re in an ICONIFIED 
state
2. Frame.isShowing() returns true
3. a java.awt.desktop.AppForegroundListener believes our app is in the 
foreground.

We want to identify when we?re in this hidden state. Is there any other 
property we can consult to help identify this state?

I?m happy to submit an openjdk ticket if needed, but first I wanted to 
sanity check that I?m not missing something. (I also tried querying 
<https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22Stage%20Manager%5C%22%22> 
the openJDK bug database, but didn?t see any hits.)

I tried rummaging around in Mac-specific classes (like CPlatformWindow), 
but I didn?t see any promising leads. It?s always possible I missed 
something, though.

Attached is a small 200-line demo app.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230216/dc959dca/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: StageManagerTest.java.zip
Type: application/zip
Size: 1973 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230216/dc959dca/StageManagerTest.java.zip>

From harshitha.onkar at oracle.com  Thu Feb 16 06:57:56 2023
From: harshitha.onkar at oracle.com (Harshitha Onkar)
Date: Thu, 16 Feb 2023 06:57:56 +0000
Subject: Stage Manager Problems
In-Reply-To: <em7c1e413a-5764-4ae1-8853-b1cf1b1e97c9@17fbc042.com>
References: <em7c1e413a-5764-4ae1-8853-b1cf1b1e97c9@17fbc042.com>
Message-ID: <BYAPR10MB3350EEB6F196F7440CF1E9AC80A09@BYAPR10MB3350.namprd10.prod.outlook.com>

Hi Jeremy,

Does any of the following options help in your case to determine whether or not the frame is iconified?


  1.  frame.isActive()
  2.  frame.isFocused()
  3.  frame.isAlwaysOnTop()

Thanks & Regards,
Harshitha Onkar

From: client-libs-dev <client-libs-dev-retn at openjdk.org> On Behalf Of Jeremy Wood
Sent: Wednesday, February 15, 2023 10:08 PM
To: client-libs-dev at openjdk.org
Subject: Stage Manager Problems

We?re experiencing problems related JFrames while Stage Manager<https://www.computerworld.com/article/3667999/what-is-apple-stage-manager-and-how-is-it-used.html> is active Mac.

When Stage Manager is active the yellow minimize button on our JFrame?s appears to ?minimize? our app. But as far as our Frame is concerned:
1. Frame.getExtendedState() does not indicate we?re in an ICONIFIED state
2. Frame.isShowing() returns true
3. a java.awt.desktop.AppForegroundListener believes our app is in the foreground.

We want to identify when we?re in this hidden state. Is there any other property we can consult to help identify this state?

I?m happy to submit an openjdk ticket if needed, but first I wanted to sanity check that I?m not missing something. (I also tried querying<https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22Stage%20Manager%5C%22%22> the openJDK bug database, but didn?t see any hits.)

I tried rummaging around in Mac-specific classes (like CPlatformWindow), but I didn?t see any promising leads. It?s always possible I missed something, though.

Attached is a small 200-line demo app.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230216/d7c7372b/attachment.htm>

From aivanov at openjdk.org  Thu Feb 16 08:45:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Feb 2023 08:45:35 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
Message-ID: <8KkVfaCMiDkQXRwgDoNDMiOaWUonVvwmxL61rM8NJxA=.f985aa52-c06f-4d8e-bbfa-a1910f6d2804@github.com>

On Thu, 16 Feb 2023 05:13:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

I would appreciate if you update the copyright year in `SwingWorker`.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11940


From mickleness at gmail.com  Thu Feb 16 10:04:11 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Thu, 16 Feb 2023 10:04:11 +0000
Subject: Stage Manager Problems
In-Reply-To: <BYAPR10MB3350EEB6F196F7440CF1E9AC80A09@BYAPR10MB3350.namprd10.prod.outlook.com>
References: <em7c1e413a-5764-4ae1-8853-b1cf1b1e97c9@17fbc042.com>
 <BYAPR10MB3350EEB6F196F7440CF1E9AC80A09@BYAPR10MB3350.namprd10.prod.outlook.com>
Message-ID: <em7b75128a-93a4-462c-a802-4a1b7a71000f@17fbc042.com>

Harshitha,

Thanks for the suggestions. I think those don?t really resolve the 
problem, though.

In the original sample program (having only 1 frame) watching the 
keyboard focus could help identify when there?s a change, but if there?s 
a second frame: that second window could retain the focus and the first 
window still can?t answer the question, ?Are you minimized now??

(I have an updated sample program 
<https://drive.google.com/file/d/1uzUUDnAlPoHlFdbVgunwpFKvn4Ies-6-/view?usp=sharing> 
here with two frames if anyone?s interested.)

Further: the window could lose the focus at any time (if a system dialog 
came up), so I don?t think focus should act as a proxy for visibility.

I did find tonight a work-around for our app a few hours ago. We have 
some native code that identifies all visible windows, their bounds and 
their title. If I consult that list: I see a window that matches our 
(sufficiently unique) window title. And its bounds do not at all match 
with what Java says our window?s bounds are. And it is positioned so 99% 
of it overlaps with a window called ?Gesture Blocking Overlay?. (All 
Stage Manager thumbnails appear to have an overlay window with this 
title.) So it?s a very kludgy and brittle work around, for for the time 
being it works.

This leads me to believe the Mac OS windowing system doesn?t consider 
the frame to be ?hidden?. I think the window remains technically 
visible. And Mac OS knows it has new bounds. But the peer in Java is 
oblivious to the new bounds/state. (I examined the peer LWWindowPeer in 
a debugger: it still thinks the window is visible (technically true) and 
its bounds are unchanged (not true).)

The more I look at this: I?m afraid the crux of this problem is Stage 
Manager has introduced a new window state that Java?s AWT architecture 
can?t really describe yet. (But I?d love to be proved wrong??)

  - Jeremy

------ Original Message ------
>From "Harshitha Onkar" <harshitha.onkar at oracle.com>
To "Jeremy Wood" <mickleness at gmail.com>
Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
Date 2/16/2023 1:57:56 AM
Subject RE: Stage Manager Problems

>Hi Jeremy,
>
>
>
>Does any of the following options help in your case to determine 
>whether or not the frame is iconified?
>
>
>
>frame.isActive()
>frame.isFocused()
>frame.isAlwaysOnTop()
>
>
>Thanks & Regards,
>
>Harshitha Onkar
>
>
>
>From: client-libs-dev <client-libs-dev-retn at openjdk.org> On Behalf Of 
>Jeremy Wood
>Sent: Wednesday, February 15, 2023 10:08 PM
>To:client-libs-dev at openjdk.org
>Subject: Stage Manager Problems
>
>
>
>We?re experiencing problems related JFrames while Stage Manager 
><https://www.computerworld.com/article/3667999/what-is-apple-stage-manager-and-how-is-it-used.html> 
>is active Mac.
>
>
>
>When Stage Manager is active the yellow minimize button on our JFrame?s 
>appears to ?minimize? our app. But as far as our Frame is concerned:
>
>1. Frame.getExtendedState() does not indicate we?re in an ICONIFIED 
>state
>
>2. Frame.isShowing() returns true
>
>3. a java.awt.desktop.AppForegroundListener believes our app is in the 
>foreground.
>
>
>
>We want to identify when we?re in this hidden state. Is there any other 
>property we can consult to help identify this state?
>
>
>
>I?m happy to submit an openjdk ticket if needed, but first I wanted to 
>sanity check that I?m not missing something. (I also tried querying 
><https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22Stage%20Manager%5C%22%22> 
>the openJDK bug database, but didn?t see any hits.)
>
>
>
>I tried rummaging around in Mac-specific classes (like 
>CPlatformWindow), but I didn?t see any promising leads. It?s always 
>possible I missed something, though.
>
>
>
>Attached is a small 200-line demo app.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230216/78dc7a2c/attachment.htm>

From abhiscxk at openjdk.org  Thu Feb 16 11:02:28 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 16 Feb 2023 11:02:28 GMT
Subject: RFR: 8300549: JFileChooser Approve button tooltip is null in Aqua
 L&F in CUSTOM_DIALOG mode [v2]
In-Reply-To: <VIAJ0-tM7BIjE5c-8vG8IfDOnMKZ-IWuExfyZPIizj4=.31771e62-e83d-4daa-a964-a55a9a1b4838@github.com>
References: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
 <VIAJ0-tM7BIjE5c-8vG8IfDOnMKZ-IWuExfyZPIizj4=.31771e62-e83d-4daa-a964-a55a9a1b4838@github.com>
Message-ID: <SrQzNRL_2oHKKElZLgHwknvmOMutVFad2vzDEGt24DQ=.1fd62344-f591-40e9-b6e1-69189f1b8e41@github.com>

On Mon, 30 Jan 2023 15:05:55 GMT, Tejesh R <tr at openjdk.org> wrote:

>> _JFilechooser_ returns _null_ for Approve button tool tip in `CUSTOM_DIALOG` mode (`getToolTipText()`). The fallback text has been set to "Choose" text. Observation found in validating the test of PR - #11901.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Property added

Marked as reviewed by abhiscxk (Committer).

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

PR: https://git.openjdk.org/jdk/pull/12198


From tr at openjdk.org  Thu Feb 16 11:13:36 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 16 Feb 2023 11:13:36 GMT
Subject: Integrated: 8300549: JFileChooser Approve button tooltip is null in
 Aqua L&F in CUSTOM_DIALOG mode
In-Reply-To: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
References: <IPLzXe7hJxn5KukI-eFxqO1CJNDO_g70pUBOlwLewIA=.68dd5394-541a-4096-8dce-99f2b6156b0d@github.com>
Message-ID: <RBD5IXjPzpUD9eQCOq7iGxMMcKaifhKzSDmY_YEOmO0=.6f606a73-d816-433b-a69a-e8526bae9af6@github.com>

On Wed, 25 Jan 2023 14:24:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> _JFilechooser_ returns _null_ for Approve button tool tip in `CUSTOM_DIALOG` mode (`getToolTipText()`). The fallback text has been set to "Choose" text. Observation found in validating the test of PR - #11901.

This pull request has now been integrated.

Changeset: 84c058bb
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84c058bb63ad68b0cb6c739453bdb81d2c9d369f
Stats:     7 lines in 2 files changed: 5 ins; 1 del; 1 mod

8300549: JFileChooser Approve button tooltip is null in Aqua L&F in CUSTOM_DIALOG mode

Reviewed-by: aivanov, abhiscxk

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

PR: https://git.openjdk.org/jdk/pull/12198


From aivanov at openjdk.org  Thu Feb 16 14:45:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Feb 2023 14:45:16 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
Message-ID: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>

The test has become unstable recently, there were quite a few failures, on Windows mostly. I was lucky enough to find a host where the test failed consistently.

I call `System.gc()` directly as suggested in comments to the bug. I used `PhantomReference` instead of `WeakReference`.

Now the test calls `System.gc()` in a loop and waits for the reference to be enqueued. In majority of cases, the test exits the loop at the second attempt.

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

Commit messages:
 - 8300727: java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java failed with "List wasn't garbage collected"

Changes: https://git.openjdk.org/jdk/pull/12594/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12594&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300727
  Stats: 53 lines in 1 file changed: 22 ins; 12 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/12594.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12594/head:pull/12594

PR: https://git.openjdk.org/jdk/pull/12594


From jwaters at openjdk.org  Thu Feb 16 15:41:21 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 15:41:21 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
Message-ID: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>

In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

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

Commit messages:
 - Brackets
 - memmove decay error

Changes: https://git.openjdk.org/jdk/pull/12597/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12597&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302671
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12597.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12597/head:pull/12597

PR: https://git.openjdk.org/jdk/pull/12597


From ihse at openjdk.org  Thu Feb 16 16:20:27 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 16 Feb 2023 16:20:27 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <7A9MKS7f2BtGoUjZEOX3sM6ykpw5R0ZwOZ_sY_8rkMM=.7355fd7f-644a-48ea-9b4b-780292786482@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

This looks bad. :-( Have you checked if this results in any user-visible broken behavior?

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

PR: https://git.openjdk.org/jdk/pull/12597


From duke at openjdk.org  Thu Feb 16 16:28:27 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Thu, 16 Feb 2023 16:28:27 GMT
Subject: RFR: 8302525: Write a test to check various components send Events
 while mouse and key are used simultaneously
In-Reply-To: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
References: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
Message-ID: <n0sjNrB7qTEzQVFo-l85GhqUe1q0fKI2Z1dtlPsbKQ0=.1183b5fd-f7d7-482a-a299-01512ad45dc4@github.com>

On Wed, 15 Feb 2023 12:50:42 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> Main aim of this testcase is to test the behavior of various events under stress.
> 
> This testcase verifies the following assertions
> a. This TestCase performs various mouse and key operations on components and checks whether all the events are getting triggered properly.
> b. It also checks some of the component specific events like item, action wherever necessary.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

Any volunteers for a review?

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

PR: https://git.openjdk.org/jdk/pull/12571


From prr at openjdk.org  Thu Feb 16 16:34:27 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Feb 2023 16:34:27 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <3pnBysAxDkjOsa1tZQy6rPdXYPOV0QFLrU1RGv7xAfk=.ed84daa7-7535-467e-bccc-fe723c90bedc@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

Umm .. I'm not sure this is correct. Have you verified ?

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

PR: https://git.openjdk.org/jdk/pull/12597


From kcr at openjdk.org  Thu Feb 16 16:44:27 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Feb 2023 16:44:27 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <KDWSLLF93ynw6CKecv04njIIHAY4Ogpx2-U0JPwYdNU=.312507d6-9f0c-4540-a96e-9c3b25c0c2f1@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

I just checked, and he is correct. In a function declaration, the array is treated as a pointer, so `sizeof(arr)` is the same as `sizeof(BYTE *)`. This even generates a compiler warning on gcc:


#include <stdio.h>

typedef unsigned char BYTE;

void do_check(BYTE arr[256]) {
    printf("check: sizeof(arr) = %ld\n", sizeof(arr));
}

int main(int argc, char** argv) {
    BYTE arr[100];
    printf("main: sizeof(arr) = %ld\n", sizeof(arr));
    do_check(arr);
}



$ cc -o foo foo.c
foo.c: In function 'do_check':
foo.c:6:48: warning: 'sizeof' on array function parameter 'arr' will return size of 'BYTE * {aka unsigned char *}' [-Wsizeof-array-argument]
     printf("check: sizeof(arr) = %ld\n", sizeof(arr));



$ ./foo
main: sizeof(arr) = 100
check: sizeof(arr) = 8

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

PR: https://git.openjdk.org/jdk/pull/12597


From lbourges at openjdk.org  Thu Feb 16 17:17:28 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 16 Feb 2023 17:17:28 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <tZuhu1wHTT_LwDC3BzFBNaI_hpFg6f03qswuTjGoA9E=.1a5f6a99-7bb2-430a-9e24-c8cb95e96c91@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

LGTM.

Length is 256*sizeof(BYTE) = 256.

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

PR: https://git.openjdk.org/jdk/pull/12597


From smarks at openjdk.org  Thu Feb 16 17:29:16 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 16 Feb 2023 17:29:16 GMT
Subject: RFR: 8302513: remove sun.awt.util.IdentityLinkedList
Message-ID: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>

IdentityLinkedList is used in only one place, so it's fairly simple to replace it with IdentityArrayList.

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

Commit messages:
 - Replace IdentityLinkedList with IdentityArrayList.

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

PR: https://git.openjdk.org/jdk/pull/12567


From serb at openjdk.org  Thu Feb 16 17:59:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Feb 2023 17:59:30 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <YS_j3kRIyR0B2s2Mjk_2k5wys9owNn1tXMlhfdSoNpQ=.82257dbc-bf97-44b8-9b8c-0e38f7d06866@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

Does anybody know how this was found, by some tool or compiler warning?

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

PR: https://git.openjdk.org/jdk/pull/12597


From jwaters at openjdk.org  Thu Feb 16 18:11:30 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 18:11:30 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <YS_j3kRIyR0B2s2Mjk_2k5wys9owNn1tXMlhfdSoNpQ=.82257dbc-bf97-44b8-9b8c-0e38f7d06866@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
 <YS_j3kRIyR0B2s2Mjk_2k5wys9owNn1tXMlhfdSoNpQ=.82257dbc-bf97-44b8-9b8c-0e38f7d06866@github.com>
Message-ID: <HZSCh3rP5vW5FyMGeqzN50lYtIyanAs5deYkZrJTHk4=.2e0a3b98-42c4-477c-9820-93156cb78b16@github.com>

On Thu, 16 Feb 2023 17:56:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Does anybody know how this was found, by some tool or compiler warning?

It was found by gcc, which will raise a noisy alert of `-Wsizeof-array-argument` and `-Wsizeof-pointer-memaccess` when compiling


awt_Component.cpp:3402:38: error: 'sizeof' on array function parameter 'kstate' will return size of 'BYTE*' {aka 'unsigned char
'} [-Werror=sizeof-array-argument]
 3402 |     memmove(tmpState, kstate, sizeof(kstate));
      |                                     ~^~~~~~~
awt_Component.cpp:3399:21: note: declared here
 3399 | resetKbdState( BYTE kstate[256]) {
      |                ~~~~~^~~~~~~~~~~
awt_Component.cpp:3402:31: error: argument to 'sizeof' in 'void* memmove(void*, const void*, size_t)' call is the same expression as the source; did you mean to provide an explicit length? [-Werror=sizeof-pointer-memaccess]
 3402 |     memmove(tmpState, kstate, sizeof(kstate));
      |                               ^~~~~~~~~~~~~~
cc1plus.exe: all warnings being treated as errors


Also related:
https://stackoverflow.com/questions/6567742/passing-an-array-as-an-argument-to-a-function-in-c
https://stackoverflow.com/questions/14309136/passing-arrays-to-function-in-c

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

PR: https://git.openjdk.org/jdk/pull/12597


From serb at openjdk.org  Thu Feb 16 18:12:28 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Feb 2023 18:12:28 GMT
Subject: RFR: 8302513: remove sun.awt.util.IdentityLinkedList
In-Reply-To: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
References: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
Message-ID: <-p936JDATr6o4GCwdFO1LkibXW21Ve9LySklgvAAJbI=.c91a4283-4e38-45f0-b0b1-25e6f0bd6079@github.com>

On Wed, 15 Feb 2023 00:11:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> IdentityLinkedList is used in only one place, so it's fairly simple to replace it with IdentityArrayList.

Looks fine. I assume it was tested by the mach5.

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

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12567


From serb at openjdk.org  Thu Feb 16 18:15:26 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Feb 2023 18:15:26 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <nrAtT7idG0l_8blKkW7OxTyPVjSlz8fXk99kp1Qlc-s=.b34ec847-121e-44e0-810c-9db9fac2fdd7@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

Marked as reviewed by serb (Reviewer).

Interesting that this code can be compiled by gcc on windows.

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

PR: https://git.openjdk.org/jdk/pull/12597


From jwaters at openjdk.org  Thu Feb 16 18:19:28 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 18:19:28 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <nrAtT7idG0l_8blKkW7OxTyPVjSlz8fXk99kp1Qlc-s=.b34ec847-121e-44e0-810c-9db9fac2fdd7@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
 <nrAtT7idG0l_8blKkW7OxTyPVjSlz8fXk99kp1Qlc-s=.b34ec847-121e-44e0-810c-9db9fac2fdd7@github.com>
Message-ID: <WDmxfEAybZXlVCaY5MRZ9sY3DIPhIQmB_OUFFrYaUEM=.ef384b7e-b903-4ea7-9da7-3d1adfb64958@github.com>

On Thu, 16 Feb 2023 18:12:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size
>
> Interesting that this code can be compiled by gcc on windows.

Much appreciated @mrserb, will leave open for a while in case there are further objections

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

PR: https://git.openjdk.org/jdk/pull/12597


From philip.race at oracle.com  Thu Feb 16 18:31:23 2023
From: philip.race at oracle.com (Philip Race)
Date: Thu, 16 Feb 2023 10:31:23 -0800
Subject: Stage Manager Problems
In-Reply-To: <em7b75128a-93a4-462c-a802-4a1b7a71000f@17fbc042.com>
References: <em7c1e413a-5764-4ae1-8853-b1cf1b1e97c9@17fbc042.com>
 <BYAPR10MB3350EEB6F196F7440CF1E9AC80A09@BYAPR10MB3350.namprd10.prod.outlook.com>
 <em7b75128a-93a4-462c-a802-4a1b7a71000f@17fbc042.com>
Message-ID: <78528704-678e-f117-1af8-83ac93b79365@oracle.com>

 >The more I look at this: I?m afraid the crux of this problem is Stage 
Manager has introduced a new window state that Java?s AWT architecture 
can?t really describe yet. (But I?d love to be proved wrong??)

I think you are right. I do not have Ventura to see / test for myself 
but everything I am hearing
sounds like with Stage Manager active the "minimise" button just causes 
a different compositing transform
to be applied to the window and adds that gesture blocking overlay to 
make it so that it can't see mouse events
or presumably receive focus for keyboard events, and the app is 
*intentionally* (as in Apple's intention)
ignorant of anything having changed in its state.

So it is anyone's guess what we can do about this and even if we should 
do something? what would it be ..
Maybe there's some clue in the latest SDK - ie a new API ?

FWIW One of our team members said he tried this mode for 5 mins but 
multiple (non-java) apps were
so broken in this mode he turned it off again.



-phil.


On 2/16/23 2:04 AM, Jeremy Wood wrote:
> Harshitha,
>
> Thanks for the suggestions. I think those don?t really resolve the 
> problem, though.
>
> In the original sample program (having only 1 frame) watching the 
> keyboard focus could help identify when there?s a change, but if 
> there?s a second frame: that second window could retain the focus and 
> the first window still can?t answer the question, ?Are you minimized now??
>
> (I have an updated sample program 
> <https://drive.google.com/file/d/1uzUUDnAlPoHlFdbVgunwpFKvn4Ies-6-/view?usp=sharing> 
> here with two frames if anyone?s interested.)
>
> Further: the window could lose the focus at any time (if a system 
> dialog came up), so I don?t think focus should act as a proxy for 
> visibility.
>
> I did find tonight a work-around for our app a few hours ago. We have 
> some native code that identifies all visible windows, their bounds and 
> their title. If I consult that list: I see a window that matches our 
> (sufficiently unique) window title. And its bounds do not at all match 
> with what Java says our window?s bounds are. And it is positioned so 
> 99% of it overlaps with a window called ?Gesture Blocking Overlay?. 
> (All Stage Manager thumbnails appear to have an overlay window with 
> this title.) So it?s a very kludgy and brittle work around, for for 
> the time being it works.
>
> This leads me to believe the Mac OS windowing system doesn?t consider 
> the frame to be ?hidden?. I think the window remains technically 
> visible. And Mac OS knows it has new bounds. But the peer in Java is 
> oblivious to the new bounds/state. (I examined the peer LWWindowPeer 
> in a debugger: it still thinks the window is visible (technically 
> true) and its bounds are unchanged (not true).)
>
> The more I look at this: I?m afraid the crux of this problem is Stage 
> Manager has introduced a new window state that Java?s AWT architecture 
> can?t really describe yet. (But I?d love to be proved wrong??)
>
> ?- Jeremy
>
> ------ Original Message ------
> From "Harshitha Onkar" <harshitha.onkar at oracle.com>
> To "Jeremy Wood" <mickleness at gmail.com>
> Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
> Date 2/16/2023 1:57:56 AM
> Subject RE: Stage Manager Problems
>
>> Hi Jeremy,
>>
>> Does any of the following options help in your case to determine 
>> whether or not the frame is iconified?
>>
>>  1. frame.isActive()
>>  2. frame.isFocused()
>>  3. frame.isAlwaysOnTop()
>>
>> Thanks & Regards,
>>
>> Harshitha Onkar
>>
>> *From:* client-libs-dev <client-libs-dev-retn at openjdk.org> *On Behalf 
>> Of *Jeremy Wood
>> *Sent:* Wednesday, February 15, 2023 10:08 PM
>> *To:* client-libs-dev at openjdk.org
>> *Subject:* Stage Manager Problems
>>
>> We?re experiencing problems related JFrames while Stage Manager 
>> <https://www.computerworld.com/article/3667999/what-is-apple-stage-manager-and-how-is-it-used.html> 
>> is active Mac.
>>
>> When Stage Manager is active the yellow minimize button on our 
>> JFrame?s appears to ?minimize? our app. But as far as our?Frame?is 
>> concerned:
>>
>> 1. Frame.getExtendedState() does not indicate we?re in an ICONIFIED state
>>
>> 2. Frame.isShowing() returns true
>>
>> 3. a java.awt.desktop.AppForegroundListener believes our app is in 
>> the foreground.
>>
>> We want to identify when we?re in this hidden state. Is there any 
>> other property we can consult to help identify this state?
>>
>> I?m happy to submit an openjdk ticket if needed, but first I wanted 
>> to sanity check that I?m not missing something. (I also tried 
>> querying 
>> <https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22Stage%20Manager%5C%22%22> 
>> the openJDK bug database, but didn?t see any hits.)
>>
>> I tried rummaging around in Mac-specific classes (like 
>> CPlatformWindow), but I didn?t see any promising leads. It?s always 
>> possible I missed something, though.
>>
>> Attached is a small 200-line demo app.
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230216/9cf00b5e/attachment.htm>

From prr at openjdk.org  Thu Feb 16 18:35:27 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Feb 2023 18:35:27 GMT
Subject: RFR: 8302513: remove sun.awt.util.IdentityLinkedList
In-Reply-To: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
References: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
Message-ID: <Rep0nGqwGyLKk6gFwKhE0pHgraXcGdr-CVwr7_3XemA=.027f5ea2-3c20-4446-9a49-118f5ad84fd3@github.com>

On Wed, 15 Feb 2023 00:11:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> IdentityLinkedList is used in only one place, so it's fairly simple to replace it with IdentityArrayList.

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12567


From prr at openjdk.org  Thu Feb 16 18:40:28 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Feb 2023 18:40:28 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <DISFd8FIoH9NUAQpFsDbCCdoEId7SdYn9tjLGRepwdA=.555c23ec-d23f-4f81-859e-b10cab807451@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12597


From prr at openjdk.org  Thu Feb 16 18:40:31 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Feb 2023 18:40:31 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <KDWSLLF93ynw6CKecv04njIIHAY4Ogpx2-U0JPwYdNU=.312507d6-9f0c-4540-a96e-9c3b25c0c2f1@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
 <KDWSLLF93ynw6CKecv04njIIHAY4Ogpx2-U0JPwYdNU=.312507d6-9f0c-4540-a96e-9c3b25c0c2f1@github.com>
Message-ID: <ezoIc4_uLqSEAvVimhZJ5P38G7qEhMegZ5P6lqsCHOA=.a68daf20-c1a0-43aa-82b5-fe50757bb9d9@github.com>

On Thu, 16 Feb 2023 16:42:05 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> I just checked, and he is correct. In a function declaration, the array is treated as a pointer, 

I see ..

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

PR: https://git.openjdk.org/jdk/pull/12597


From kcr at openjdk.org  Thu Feb 16 18:50:27 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 16 Feb 2023 18:50:27 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <z_c11C4laFKBt4jlTxBAvQaDG3ZZnzpcK0JOvmnrZNg=.a66888cf-9e24-4c5f-937e-34cca0abba44@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

Marked as reviewed by kcr (Author).

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

PR: https://git.openjdk.org/jdk/pull/12597


From serb at openjdk.org  Thu Feb 16 19:01:38 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Feb 2023 19:01:38 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
Message-ID: <3vWpzMBf0CT4aiRdlwxUkqmHhRw7Kwuiyjc0JEcn-Zw=.2e8a4b8b-0d01-4ff8-98b3-22ed93047e0c@github.com>

On Thu, 16 Feb 2023 05:13:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test fix

src/java.desktop/share/classes/javax/swing/SwingWorker.java line 308:

> 306:                         } finally {
> 307:                             doneEDT();
> 308:                             setState(StateValue.DONE);

Can the test checks the case when the listener called from "setState" will throw an exception, I think some of the previous iterations of the fix will not work in this case.

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

PR: https://git.openjdk.org/jdk/pull/11940


From jwaters at openjdk.org  Thu Feb 16 19:02:36 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Feb 2023 19:02:36 GMT
Subject: Integrated: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <q-BLPfpgopBZ3JAPFksd8eqHvH_fnOQdC7p4tmPvsF4=.34d479b5-ca8d-46e4-b11c-d62b109c9f27@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

This pull request has now been integrated.

Changeset: e5042dd4
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e5042dd483d54216d0e82624bb964d9e029af484
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8302671: libawt has a memmove decay error

Reviewed-by: serb, prr, kcr

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

PR: https://git.openjdk.org/jdk/pull/12597


From aivanov at openjdk.org  Thu Feb 16 19:15:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Feb 2023 19:15:36 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <3vWpzMBf0CT4aiRdlwxUkqmHhRw7Kwuiyjc0JEcn-Zw=.2e8a4b8b-0d01-4ff8-98b3-22ed93047e0c@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
 <3vWpzMBf0CT4aiRdlwxUkqmHhRw7Kwuiyjc0JEcn-Zw=.2e8a4b8b-0d01-4ff8-98b3-22ed93047e0c@github.com>
Message-ID: <JnoGqwHswvihTKZTXRC60EbNT9HXvovh6JT_AEw_l2s=.010b22a9-c72a-4007-bb0e-82a717242e66@github.com>

On Thu, 16 Feb 2023 18:59:07 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Can the test checks the case when the listener called from "setState" will throw an exception, I think some of the previous iterations of the fix will not work in this case.

This is not a new problem and _is not introduced_ by Prasanta's fix.

I also found it while I was testing his changes and ran the test.

If a listener throws an exception, all the following runnables which are already accumulated in `AccumulativeRunnable` are not run.

I have already written a test for this case and I will submit a bug. It must not be included here.

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

PR: https://git.openjdk.org/jdk/pull/11940


From duke at openjdk.org  Thu Feb 16 21:14:36 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 16 Feb 2023 21:14:36 GMT
Subject: RFR: 8302495: update for deprecated sprintf for java.desktop
In-Reply-To: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
References: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
Message-ID: <fUkpfSDEXLF-BvvY63av82RHzgrmYzcZRE8J7A8R_Jk=.d67a1c0d-89a1-492f-aae6-1eda12c3a08e@github.com>

On Tue, 14 Feb 2023 20:41:39 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in java.desktop components.
> 
> Thanks,
> Xuelei

Looks good.

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

PR: https://git.openjdk.org/jdk/pull/12565


From serb at openjdk.org  Thu Feb 16 21:22:37 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Feb 2023 21:22:37 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <JnoGqwHswvihTKZTXRC60EbNT9HXvovh6JT_AEw_l2s=.010b22a9-c72a-4007-bb0e-82a717242e66@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
 <3vWpzMBf0CT4aiRdlwxUkqmHhRw7Kwuiyjc0JEcn-Zw=.2e8a4b8b-0d01-4ff8-98b3-22ed93047e0c@github.com>
 <JnoGqwHswvihTKZTXRC60EbNT9HXvovh6JT_AEw_l2s=.010b22a9-c72a-4007-bb0e-82a717242e66@github.com>
Message-ID: <LTOBufkHzG-oSK9Rv_crU73l4ySN9PjVVISijHlsbbc=.404620bd-7331-4792-b53d-939a6f71f271@github.com>

On Thu, 16 Feb 2023 19:12:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/SwingWorker.java line 308:
>> 
>>> 306:                         } finally {
>>> 307:                             doneEDT();
>>> 308:                             setState(StateValue.DONE);
>> 
>> Can the test checks the case when the listener called from "setState" will throw an exception, I think some of the previous iterations of the fix will not work in this case.
>
>> Can the test checks the case when the listener called from "setState" will throw an exception, I think some of the previous iterations of the fix will not work in this case.
> 
> This is not a new problem and _is not introduced_ by Prasanta's fix.
> 
> I also found it while I was testing his changes and ran the test.
> 
> If a listener throws an exception, all the following runnables which are already accumulated in `AccumulativeRunnable` are not run.
> 
> I have already written a test for this case and I will submit a bug. It must not be included here.

I think the previous iteration of the fix was not run the doneEDT if the setState throws an exception, while the current version, and initial code always run it.

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

PR: https://git.openjdk.org/jdk/pull/11940


From prr at openjdk.org  Thu Feb 16 21:51:22 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Feb 2023 21:51:22 GMT
Subject: RFR: 8302495: update for deprecated sprintf for java.desktop
In-Reply-To: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
References: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
Message-ID: <MGbT7kXybrpTCiM4cFtciem4W6zPHumw0V8G4B9nsPM=.be07ee3b-5582-432b-afd4-627fda3480ea@github.com>

On Tue, 14 Feb 2023 20:41:39 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in java.desktop components.
> 
> Thanks,
> Xuelei

This is a fairly extensive set of changes so I'll contact you off-line to make sure you have done adequate testing.

Also the changes in freetype must be reverted. This is a 3rd party library.

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

PR: https://git.openjdk.org/jdk/pull/12565


From aivanov at openjdk.org  Thu Feb 16 21:51:47 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Feb 2023 21:51:47 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <LTOBufkHzG-oSK9Rv_crU73l4ySN9PjVVISijHlsbbc=.404620bd-7331-4792-b53d-939a6f71f271@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
 <3vWpzMBf0CT4aiRdlwxUkqmHhRw7Kwuiyjc0JEcn-Zw=.2e8a4b8b-0d01-4ff8-98b3-22ed93047e0c@github.com>
 <JnoGqwHswvihTKZTXRC60EbNT9HXvovh6JT_AEw_l2s=.010b22a9-c72a-4007-bb0e-82a717242e66@github.com>
 <LTOBufkHzG-oSK9Rv_crU73l4ySN9PjVVISijHlsbbc=.404620bd-7331-4792-b53d-939a6f71f271@github.com>
Message-ID: <gbbXUqfDhgqCRJuV_6BZZRu7s80s9liIUUIq4BHsql8=.bc625e7d-8372-48d4-967c-6f5c3d003ecc@github.com>

On Thu, 16 Feb 2023 21:19:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> I think the previous iteration of the fix was not run the doneEDT if the setState throws an exception, while the current version, and initial code always run it.

It depends?

If you change the order of the `doneEDT` and state, the listener throws the exception (as expected to fail the test) ? then `done` isn't run because of the problem I just described above. It's an inherent problem in the implementation of `SwingWorker`. If you revert to the order of the calls in the latest revision and throw an exception from `done`, then listener for `DONE` state is not called.

It's a different bug which exists *with and without* the fix we're currently discussing.

I can repeat: I have a test which demonstrates the problem that you see now. The test reproduces the problem on any current build of Java (okay, I tested 17, 19 and 21). I will submit a new bug for it.

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Thu Feb 16 21:53:04 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Feb 2023 21:53:04 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
Message-ID: <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>

On Thu, 16 Feb 2023 14:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test has become unstable recently, there were quite a few failures, on Windows mostly. I was lucky enough to find a host where the test failed consistently.
> 
> I call `System.gc()` directly as suggested in comments to the bug. I used `PhantomReference` instead of `WeakReference`.
> 
> Now the test calls `System.gc()` in a loop and waits for the reference to be enqueued. In majority of cases, the test exits the loop at the second attempt.

test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java line 72:

> 70:         do {
> 71:             System.out.println("Attempt " + count);
> 72:             System.gc();

As far as I remember the call of System.gc() could be ignored, and the only way to trigger GC is to trigger the OOM. Probably we can combine referenceQueue.remove(ENQUEUE_TIMEOUT) + OOM?

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

PR: https://git.openjdk.org/jdk/pull/12594


From aivanov at openjdk.org  Thu Feb 16 21:53:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Feb 2023 21:53:05 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>
Message-ID: <Mt6Vv2YjMnw1SSrvWkX06N91CWwKnlJu_cPtxhXD7KY=.891d231c-5081-4f4c-88cc-53cbde4df3b5@github.com>

On Thu, 16 Feb 2023 21:41:12 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The test has become unstable recently, there were quite a few failures, on Windows mostly. I was lucky enough to find a host where the test failed consistently.
>> 
>> I call `System.gc()` directly as suggested in comments to the bug. I used `PhantomReference` instead of `WeakReference`.
>> 
>> Now the test calls `System.gc()` in a loop and waits for the reference to be enqueued. In majority of cases, the test exits the loop at the second attempt.
>
> test/jdk/java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java line 72:
> 
>> 70:         do {
>> 71:             System.out.println("Attempt " + count);
>> 72:             System.gc();
> 
> As far as I remember the call of System.gc() could be ignored, and the only way to trigger GC is to trigger the OOM. Probably we can combine referenceQueue.remove(ENQUEUE_TIMEOUT) + OOM?

For this reason, GC logs are enabled. If, for whatever reason, the call to `System.gc()` is ignored, we'll see it in the test log. Then a specific GC could be selected, for example, or another fix implemented.

OOME does not guarantee a full GC cycle either.

Having the above in mind, I'd rather keep it simple.

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

PR: https://git.openjdk.org/jdk/pull/12594


From serb at openjdk.org  Fri Feb 17 03:10:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Feb 2023 03:10:08 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <Mt6Vv2YjMnw1SSrvWkX06N91CWwKnlJu_cPtxhXD7KY=.891d231c-5081-4f4c-88cc-53cbde4df3b5@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>
 <Mt6Vv2YjMnw1SSrvWkX06N91CWwKnlJu_cPtxhXD7KY=.891d231c-5081-4f4c-88cc-53cbde4df3b5@github.com>
Message-ID: <Qekkj0igM94vCQHF9RTZRrrDmqBbPGVBN2o3wtUhpIw=.77da8875-992e-4872-9cdf-8bb3b92438cd@github.com>

On Thu, 16 Feb 2023 21:50:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>For this reason, GC logs are enabled. If, for whatever reason, the call to System.gc() is ignored, we'll see it in the test log. Then a specific GC could be selected, for example, or another fix implemented.

As of now this test can be executed with different GC, and some of them can skip System.gc().

>OOME does not guarantee a full GC cycle either.

But it guarantee that at list some GC will be always run, unlike System.gc().

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

PR: https://git.openjdk.org/jdk/pull/12594


From psadhukhan at openjdk.org  Fri Feb 17 03:24:40 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 17 Feb 2023 03:24:40 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v22]
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <FuRd_a8Vf7ylbGdh4gDWVtzkJp0UGdQYL9vT4Ttxqrk=.08ccc695-639a-4534-a339-64a3d6ed0570@github.com>

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

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

  Copyright year updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11940/files
  - new: https://git.openjdk.org/jdk/pull/11940/files/22ef8f51..9d12744f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11940&range=20-21

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

PR: https://git.openjdk.org/jdk/pull/11940


From tr at openjdk.org  Fri Feb 17 11:00:03 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 17 Feb 2023 11:00:03 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <QjPugzqKOykagX8b9VuQ65VKvwhVKErd1ShOI_0VhUs=.c70d7114-6710-40a8-82db-f591908789f0@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
 <QjPugzqKOykagX8b9VuQ65VKvwhVKErd1ShOI_0VhUs=.c70d7114-6710-40a8-82db-f591908789f0@github.com>
Message-ID: <xTlSiMOJ8fiFwlGzl_88kHZVgjcY4CMEVeSxxx69vng=.a1483921-629b-4c67-be49-68fead39ba79@github.com>

On Tue, 17 Jan 2023 17:01:39 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused imports
>
> The updates look good. Everything working as expected when ran with changes.

@DamonGuy @kumarabhi006 @aivanov-jdk Can u please re-review the PR and see if its ok, since other dependent PR's have been Integrated.

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

PR: https://git.openjdk.org/jdk/pull/11901


From aivanov at openjdk.org  Fri Feb 17 13:03:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Feb 2023 13:03:51 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v22]
In-Reply-To: <FuRd_a8Vf7ylbGdh4gDWVtzkJp0UGdQYL9vT4Ttxqrk=.08ccc695-639a-4534-a339-64a3d6ed0570@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <FuRd_a8Vf7ylbGdh4gDWVtzkJp0UGdQYL9vT4Ttxqrk=.08ccc695-639a-4534-a339-64a3d6ed0570@github.com>
Message-ID: <kG-R-Q2nZ0tF1kNkyUzI0WB1NOm9QCAOh2l60e3uk7s=.0030c9ef-a782-43dd-9377-53e1dd64feee@github.com>

On Fri, 17 Feb 2023 03:24:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year updated

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11940


From jwaters at openjdk.org  Fri Feb 17 14:07:25 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Feb 2023 14:07:25 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <S_iuuaJCgPWBJ0stThTPvtMOuIFH8qa9lk2q222mI_I=.5da4a9b9-db84-4a94-982d-c4d3e4fa9d97@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

Looking back at this now, I wonder if we should also have changed the parameter from `kstate[256]` to `*kstate` instead, to make it clear that C++ cannot pass an array like this and that the type of kstate is a pointer and not an array, to avoid the misconception that you can use sizeof on it

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

PR: https://git.openjdk.org/jdk/pull/12597


From lbourges at openjdk.org  Fri Feb 17 14:58:50 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Fri, 17 Feb 2023 14:58:50 GMT
Subject: RFR: 8302671: libawt has a memmove decay error
In-Reply-To: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
References: <zsJkDwCwZU3TOpKB8Tunn0ueAMlTvb8qw6y4mJMZv9c=.f8b5b52e-1730-4bc2-a88c-e88478d4f6cb@github.com>
Message-ID: <hIZRHwV_PmbhDtXb9j7JiBCjSXyJlnUia6tG36FmaVY=.a8383da4-b369-4644-8cb3-c4b2549589a7@github.com>

On Thu, 16 Feb 2023 15:33:51 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In libawt, the size parameter is issued by a sizeof on an array, which as expected decays into a pointer and breaks the cleanup code by giving the incorrect size

Or use #define KBD_BUF_LEN 256
And use it explicitely in array init & memmove... as plain old C.

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

PR: https://git.openjdk.org/jdk/pull/12597


From aivanov at openjdk.org  Fri Feb 17 14:58:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Feb 2023 14:58:52 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
Message-ID: <ExVQlBIIbvsMfexveS3hZEsTxHHa5WU9viYPTWRqM1c=.8eb587cf-72e5-4ace-bdc7-c38efdfc3e41@github.com>

On Tue, 17 Jan 2023 05:37:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

Please update the copyright year in `BasicFileChooserUI.java`.

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11901


From aivanov at openjdk.org  Fri Feb 17 15:48:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Feb 2023 15:48:05 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <LTOBufkHzG-oSK9Rv_crU73l4ySN9PjVVISijHlsbbc=.404620bd-7331-4792-b53d-939a6f71f271@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
 <3vWpzMBf0CT4aiRdlwxUkqmHhRw7Kwuiyjc0JEcn-Zw=.2e8a4b8b-0d01-4ff8-98b3-22ed93047e0c@github.com>
 <JnoGqwHswvihTKZTXRC60EbNT9HXvovh6JT_AEw_l2s=.010b22a9-c72a-4007-bb0e-82a717242e66@github.com>
 <LTOBufkHzG-oSK9Rv_crU73l4ySN9PjVVISijHlsbbc=.404620bd-7331-4792-b53d-939a6f71f271@github.com>
Message-ID: <MEe9ed2GQjGRZ_9pz5lJlbhu61aqEBMc3ZkYe0S-BpI=.d9af47c9-755f-492f-97e5-6d4ede8e3d35@github.com>

On Thu, 16 Feb 2023 21:19:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> Can the test checks the case when the listener called from "setState" will throw an exception, I think some of the previous iterations of the fix will not work in this case.
>> 
>> This is not a new problem and _is not introduced_ by Prasanta's fix.
>> 
>> I also found it while I was testing his changes and ran the test.
>> 
>> If a listener throws an exception, all the following runnables which are already accumulated in `AccumulativeRunnable` are not run.
>> 
>> I have already written a test for this case and I will submit a bug. It must not be included here.
>
> I think the previous iteration of the fix was not run the doneEDT if the setState throws an exception, while the current version, and initial code always run it.

@mrserb I have submitted [JDK-8302778](https://bugs.openjdk.org/browse/JDK-8302778): _SwingWorker loses notifications if a handler throws an exception_.

The provided [LostNotifications.java](https://github.com/aivanov-jdk/jdk/blob/e4042edc654849a992710a0e0d23ec8df4fe14c4/test/jdk/javax/swing/SwingWorker/LostNotifications.java) test fails on 8, 11, 17 and 21.

It proves that this problem is not related to the current fix, however, the test for this issue has uncovered it.

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

PR: https://git.openjdk.org/jdk/pull/11940


From dnguyen at openjdk.org  Fri Feb 17 19:53:02 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Feb 2023 19:53:02 GMT
Subject: RFR: 7093691: Nimbus LAF: disabled JComboBox using renderer has
 bad font color [v6]
In-Reply-To: <FM44N03SBOGGiCnGDwH9s4pXVpReUYRQaR--J8BXFN4=.19fb3f9c-7597-4048-a90b-e74676df9cf3@github.com>
References: <Wmk6y0vtfpx0P5acgWa0HnDocv5yULoYCJp_QVQhUAg=.197dce20-70e6-4892-93b9-d91851d81745@github.com>
 <FM44N03SBOGGiCnGDwH9s4pXVpReUYRQaR--J8BXFN4=.19fb3f9c-7597-4048-a90b-e74676df9cf3@github.com>
Message-ID: <d74MQGs4iSF77AApzoML8fasm54e34vft2ZhphBIURk=.641c05d7-ad8d-43f2-a59f-697a3797032b@github.com>

On Tue, 14 Feb 2023 19:11:20 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Before the fix, a JComboBox in Nimbus L&F would have normal black text even when the JComboBox was disabled if SynthComboBoxRenderer was replaced with a DefaultListCellRenderer. This text should be greyed out like in other L&F's. When looking into the defaults for Nimbus L&F files for attributes and states of a JComboBox, it confirm that the intention for disabled JComboBoxes is nimbusDisabledText (which is grey text).
>> 
>> SynthComboBoxes have an additional check in its default SynthComboBoxRenderer that enables/disables the renderer itself. The SynthComboBoxRenderer inherits its enabled state from the parent ComboBox. Since the renderer with DefaultListCellRenderer is in a separate class without a reference to the comboBox, a listener was added to SynthComboBoxUI.
>> 
>> An additional issue occurred in DefaultListCellRenderer because the renderer overrode the listener's re-assigned enabled state. In testing, setting the enabled state in DefaultListCellRenderer is redundant for all L&F's and is not needed here. However, instead of removing it altogether, a conditional was added specifically to allow ComboBoxes to skip setting enabled state here.
>> 
>> After the fix, the Nimbus JComboBox with DLCR set matches the appearance of a normal Nimbus JComboBox. I can enable/disable the JComboBoxes in the test, and the UI elements behave and appear as expected.
>
> Damon Nguyen has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Remove extra bufferedImage
>  - Fix crlf
>  - Add automated test. Cycle thru all LAF
>  - Add testing for other LAFs

> extends DefaultListCellRenderer.UIResource

I tried implementing this after your suggestion, but it doesn't achieve the wanted result. This makes sense from my understanding because with a new comboBox set to using a new DefaultListCellRenderer, the SynthComboBoxRenderer wouldn't be used. Changing what is extended for SynthComboBoxRenderer would only affect the normal comboBox using the default Synth renderer. The listener is the way around this because the comboBox with a DLCR still is a SynthComboBox but does not rely on the SynthComboBoxRenderer.

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

PR: https://git.openjdk.org/jdk/pull/12390


From serb at openjdk.org  Fri Feb 17 20:08:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Feb 2023 20:08:11 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v22]
In-Reply-To: <FuRd_a8Vf7ylbGdh4gDWVtzkJp0UGdQYL9vT4Ttxqrk=.08ccc695-639a-4534-a339-64a3d6ed0570@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <FuRd_a8Vf7ylbGdh4gDWVtzkJp0UGdQYL9vT4Ttxqrk=.08ccc695-639a-4534-a339-64a3d6ed0570@github.com>
Message-ID: <1TgX0fUJApuzmpKOgoZQlsDiNSGLUxvxi7atqI6w9NY=.5bd89a4e-d795-40ea-bb7a-cb65ba3557c3@github.com>

On Fri, 17 Feb 2023 03:24:40 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
>> but there's no mechanism in place to honor that claim.
>> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
>> also says the state should be DONE after doInBackground() returns which is also not done.
>> 
>> Modified the code to honour the specification.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year updated

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11940


From serb at openjdk.org  Fri Feb 17 20:08:13 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Feb 2023 20:08:13 GMT
Subject: RFR: 8081474: SwingWorker calls 'done' before the 'doInBackground'
 is finished [v21]
In-Reply-To: <MEe9ed2GQjGRZ_9pz5lJlbhu61aqEBMc3ZkYe0S-BpI=.d9af47c9-755f-492f-97e5-6d4ede8e3d35@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
 <tWmTI5-mCx5nbT-r-syrQ4lkAMzEytUDcGzYLT8zqm8=.415251be-ba76-4109-a0e6-064b8695d919@github.com>
 <3vWpzMBf0CT4aiRdlwxUkqmHhRw7Kwuiyjc0JEcn-Zw=.2e8a4b8b-0d01-4ff8-98b3-22ed93047e0c@github.com>
 <JnoGqwHswvihTKZTXRC60EbNT9HXvovh6JT_AEw_l2s=.010b22a9-c72a-4007-bb0e-82a717242e66@github.com>
 <LTOBufkHzG-oSK9Rv_crU73l4ySN9PjVVISijHlsbbc=.404620bd-7331-4792-b53d-939a6f71f271@github.com>
 <MEe9ed2GQjGRZ_9pz5lJlbhu61aqEBMc3ZkYe0S-BpI=.d9af47c9-755f-492f-97e5-6d4ede8e3d35@github.com>
Message-ID: <JvRP4bWQ_2GJCi0k0skC8Tos2zppyqUicLYsE6OU0ZE=.c25b21c1-4e0a-40d0-8c0e-bfbd4b4d0921@github.com>

On Fri, 17 Feb 2023 15:35:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I think the previous iteration of the fix was not run the doneEDT if the setState throws an exception, while the current version, and initial code always run it.
>
> @mrserb I have submitted [JDK-8302778](https://bugs.openjdk.org/browse/JDK-8302778): _SwingWorker loses notifications if a handler throws an exception_.
> 
> The provided [LostNotifications.java](https://github.com/aivanov-jdk/jdk/blob/e4042edc654849a992710a0e0d23ec8df4fe14c4/test/jdk/javax/swing/SwingWorker/LostNotifications.java) test fails on 8, 11, 17 and 21.
> 
> It proves that this problem is not related to the current fix, however, the test for this issue has uncovered it.

That look fine.

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

PR: https://git.openjdk.org/jdk/pull/11940


From dnguyen at openjdk.org  Fri Feb 17 22:53:32 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Feb 2023 22:53:32 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v12]
In-Reply-To: <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <vE-ArlIXwQu9LpLvZAp-0ZxyBGDSeBfTwPlnoMiMPRs=.78543b1e-ded3-4617-904a-226c2bf6318f@github.com>
Message-ID: <LiN4VPERUrE85l6OfgLm-thRggm0vAlqDMcl9vRA6hY=.9f201400-56f2-4eef-9d79-66f45fdb4e65@github.com>

On Tue, 17 Jan 2023 05:37:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

Changes still LGTM. I re-synced my repos and tried with and without your changes. The previous comments seem to be addressed as well. Just the copyright year still as previously commented.

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

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk/pull/11901


From mickleness at gmail.com  Sat Feb 18 10:22:25 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Sat, 18 Feb 2023 10:22:25 +0000
Subject: Stage Manager Problems
In-Reply-To: <78528704-678e-f117-1af8-83ac93b79365@oracle.com>
References: <em7c1e413a-5764-4ae1-8853-b1cf1b1e97c9@17fbc042.com>
 <BYAPR10MB3350EEB6F196F7440CF1E9AC80A09@BYAPR10MB3350.namprd10.prod.outlook.com>
 <em7b75128a-93a4-462c-a802-4a1b7a71000f@17fbc042.com>
 <78528704-678e-f117-1af8-83ac93b79365@oracle.com>
Message-ID: <emc3b9f388-53f2-404a-b4eb-8757cebbcbd6@cecdd4f4.com>

I made a 5 min video here:

https://drive.google.com/file/d/1al0huWBGhdSeqXrNU_if8HpQGOrxFMFH/view?usp=sharing

(I?ll delete this link in a month or two.)

It shows the original complaint, but also around t=3 min it starts to 
show a worse problem:

If you have Stage Manager active and you iconify a JFrame, the JFrame 
never returns to a Frame.NORMAL state. (At least not in this simple 
test.) This leads to major repaint problems.

So? my immediate question is: now what?

Should I take what I have and just submit an openJDK ticket? (Or a 
separate ticket for each problem?) Is it OK to write a ticket with an 
undefined expected behavior, or is that something we should try to 
clarify here first?

Regards,
  - Jeremy


------ Original Message ------
>From "Philip Race" <philip.race at oracle.com>
To "Jeremy Wood" <mickleness at gmail.com>; "Harshitha Onkar" 
<harshitha.onkar at oracle.com>
Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
Date 2/16/2023 1:31:23 PM
Subject Re: Stage Manager Problems

> >The more I look at this: I?m afraid the crux of this problem is Stage 
>Manager has introduced a new window state that Java?s AWT architecture 
>can?t really describe yet. (But I?d love to be proved wrong??)
>
>I think you are right. I do not have Ventura to see / test for myself 
>but everything I am hearing
>sounds like with Stage Manager active the "minimise" button just causes 
>a different compositing transform
>to be applied to the window and adds that gesture blocking overlay to 
>make it so that it can't see mouse events
>or presumably receive focus for keyboard events, and the app is 
>*intentionally* (as in Apple's intention)
>ignorant of anything having changed in its state.
>
>So it is anyone's guess what we can do about this and even if we should 
>do something  what would it be ..
>Maybe there's some clue in the latest SDK - ie a new API ?
>
>FWIW One of our team members said he tried this mode for 5 mins but 
>multiple (non-java) apps were
>so broken in this mode he turned it off again.
>
>
>
>-phil.
>
>
>On 2/16/23 2:04 AM, Jeremy Wood wrote:
>>Harshitha,
>>
>>Thanks for the suggestions. I think those don?t really resolve the 
>>problem, though.
>>
>>In the original sample program (having only 1 frame) watching the 
>>keyboard focus could help identify when there?s a change, but if 
>>there?s a second frame: that second window could retain the focus and 
>>the first window still can?t answer the question, ?Are you minimized 
>>now??
>>
>>(I have an updated sample program 
>><https://drive.google.com/file/d/1uzUUDnAlPoHlFdbVgunwpFKvn4Ies-6-/view?usp=sharing> 
>>here with two frames if anyone?s interested.)
>>
>>Further: the window could lose the focus at any time (if a system 
>>dialog came up), so I don?t think focus should act as a proxy for 
>>visibility.
>>
>>I did find tonight a work-around for our app a few hours ago. We have 
>>some native code that identifies all visible windows, their bounds and 
>>their title. If I consult that list: I see a window that matches our 
>>(sufficiently unique) window title. And its bounds do not at all match 
>>with what Java says our window?s bounds are. And it is positioned so 
>>99% of it overlaps with a window called ?Gesture Blocking Overlay?. 
>>(All Stage Manager thumbnails appear to have an overlay window with 
>>this title.) So it?s a very kludgy and brittle work around, for for 
>>the time being it works.
>>
>>This leads me to believe the Mac OS windowing system doesn?t consider 
>>the frame to be ?hidden?. I think the window remains technically 
>>visible. And Mac OS knows it has new bounds. But the peer in Java is 
>>oblivious to the new bounds/state. (I examined the peer LWWindowPeer 
>>in a debugger: it still thinks the window is visible (technically 
>>true) and its bounds are unchanged (not true).)
>>
>>The more I look at this: I?m afraid the crux of this problem is Stage 
>>Manager has introduced a new window state that Java?s AWT architecture 
>>can?t really describe yet. (But I?d love to be proved wrong??)
>>
>>  - Jeremy
>>
>>------ Original Message ------
>>From "Harshitha Onkar" <harshitha.onkar at oracle.com>
>>To "Jeremy Wood" <mickleness at gmail.com>
>>Cc "client-libs-dev at openjdk.org" < client-libs-dev at openjdk.org>
>>Date 2/16/2023 1:57:56 AM
>>Subject RE: Stage Manager Problems
>>
>>>Hi Jeremy,
>>>
>>>
>>>
>>>Does any of the following options help in your case to determine 
>>>whether or not the frame is iconified?
>>>
>>>
>>>
>>>frame.isActive()
>>>frame.isFocused()
>>>frame.isAlwaysOnTop()
>>>
>>>
>>>Thanks & Regards,
>>>
>>>Harshitha Onkar
>>>
>>>
>>>
>>>From: client-libs-dev <client-libs-dev-retn at openjdk.org> On Behalf Of 
>>>Jeremy Wood
>>>Sent: Wednesday, February 15, 2023 10:08 PM
>>>To:client-libs-dev at openjdk.org
>>>Subject: Stage Manager Problems
>>>
>>>
>>>
>>>We?re experiencing problems related JFrames while  Stage Manager 
>>><https://www.computerworld.com/article/3667999/what-is-apple-stage-manager-and-how-is-it-used.html> 
>>>is active Mac.
>>>
>>>
>>>
>>>When Stage Manager is active the yellow minimize button on our 
>>>JFrame?s appears to ?minimize? our app. But as far as our Frame is 
>>>concerned:
>>>
>>>1. Frame.getExtendedState() does not indicate we?re in an ICONIFIED 
>>>state
>>>
>>>2. Frame.isShowing() returns true
>>>
>>>3. a java.awt.desktop.AppForegroundListener believes our app is in 
>>>the foreground.
>>>
>>>
>>>
>>>We want to identify when we?re in this hidden state. Is there any 
>>>other property we can consult to help identify this state?
>>>
>>>
>>>
>>>I?m happy to submit an openjdk ticket if needed, but first I wanted 
>>>to sanity check that I?m not missing something. (I also tried 
>>>querying 
>>><https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22Stage%20Manager%5C%22%22> 
>>>the openJDK bug database, but didn?t see any hits.)
>>>
>>>
>>>
>>>I tried rummaging around in Mac-specific classes (like 
>>>CPlatformWindow), but I didn?t see any promising leads. It?s always 
>>>possible I missed something, though.
>>>
>>>
>>>
>>>Attached is a small 200-line demo app.
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230218/58283b0c/attachment.htm>

From duke at openjdk.org  Sat Feb 18 11:49:23 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 18 Feb 2023 11:49:23 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v2]
In-Reply-To: <H2-rtfxP-wKnL-klTE-an6aS5AOV6Ai2eeGMtqWRlbo=.cdc79af2-00b0-4b07-be5a-c69807c743ad@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
 <y3J9iKiUgSyeLZGbDKZzHTPq3MfshKmIMuwrx3lhU04=.0a3e8f31-aa3b-46cd-84c3-27f47f321220@github.com>
 <H2-rtfxP-wKnL-klTE-an6aS5AOV6Ai2eeGMtqWRlbo=.cdc79af2-00b0-4b07-be5a-c69807c743ad@github.com>
Message-ID: <71NAtiNJkyltbYyAqCGH09KgePUetiFL_QPKVLXy1RM=.2f6540ff-95ce-4f85-949e-6a12063ff23c@github.com>

On Mon, 13 Feb 2023 21:03:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added @since
>
> oh, and in future discuss things like this on the list and get agreement BEFORE posting a PR.
> See https://openjdk.org/groups/client-libs/
> "Proposing a change" where this is discussed.

@prrace Phil, thank you for your comments. I am very sorry to not have followed the rules of the client-libs group, and sorry for this confusing and erroneous PR. I didn't want to be disruptive, I just was used this way of contribution from my work at the core-libs group. I will suspend this PR by switching it to draft mode, and restart the discussion on the mailing list. Thanks a lot, and again sorry.

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

PR: https://git.openjdk.org/jdk/pull/12098


From duke at openjdk.org  Sat Feb 18 12:09:34 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 18 Feb 2023 12:09:34 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v3]
In-Reply-To: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
Message-ID: <lDw8OixIzlaFxANfjsiJZwJiHF3v8F25lF9I2lA2ueo=.14602ee6-1bb6-49d7-9979-0d11ccacc3ae@github.com>

> ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.
> 
> There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.
> 
> This is not a big change, but it is useful for those working with ImageIO.

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

  ImageInputStream already implements Closable, no need for AutoClosable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12098/files
  - new: https://git.openjdk.org/jdk/pull/12098/files/7991ea30..963cb65d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/12098


From duke at openjdk.org  Sat Feb 18 12:15:38 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 18 Feb 2023 12:15:38 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v4]
In-Reply-To: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
Message-ID: <GQ7FkOA08bvhdaxdr8EsIPuwwmmTtstar-8Y7sKpVOQ=.0685b4f3-924e-4dd4-a96c-cb260d1a561e@github.com>

> ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.
> 
> There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.
> 
> This is not a big change, but it is useful for those working with ImageIO.

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

  Corrected @since

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12098/files
  - new: https://git.openjdk.org/jdk/pull/12098/files/963cb65d..f5a5f091

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12098


From duke at openjdk.org  Sat Feb 18 12:28:36 2023
From: duke at openjdk.org (Markus KARG)
Date: Sat, 18 Feb 2023 12:28:36 GMT
Subject: RFR: JDK-8302281 - ImageIO objects should implement AutoClosable
 [v5]
In-Reply-To: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
References: <kEKlEOrdx0EXheo_yavfjw7MWndCcN0XxLihq-RAoNM=.c9ea088e-fc89-423b-b6e0-a535f73a2034@github.com>
Message-ID: <CJ5moiZqbDuw2nnMU1AF4mJMKlPtXNASIInxQL7n52k=.e34ace55-53e6-4c61-90f0-29e99033c26a@github.com>

> ImageIO objects, like ImageReader, ImageWrite, ImageInputStream and ImageOutputStream, should implement AutoClosable.
> 
> There is a risk of keeping resources opened longer than needed (or even run into a resource leak with long running processes) as the user cannot use try-with-resources currently. The fact that there is a `dispose()` method to be called is easily missed, as people tend to look for `close()`.
> 
> This is not a big change, but it is useful for those working with ImageIO.

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

  Closeable instead of AutoCloseable

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12098/files
  - new: https://git.openjdk.org/jdk/pull/12098/files/f5a5f091..4aceea1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12098&range=03-04

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12098.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12098/head:pull/12098

PR: https://git.openjdk.org/jdk/pull/12098


From duke at openjdk.org  Sat Feb 18 22:25:09 2023
From: duke at openjdk.org (SWinxy)
Date: Sat, 18 Feb 2023 22:25:09 GMT
Subject: RFR: 8302813: awt.image.incrementaldraw can use Boolean.parseBoolean()
 to parse the system property
Message-ID: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>

Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.

Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

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

Commit messages:
 - Make isInc private
 - awt.image.incrementaldraw can use Boolean.parseBoolean() to parse the system property

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

PR: https://git.openjdk.org/jdk/pull/12639


From serb at openjdk.org  Sat Feb 18 22:25:23 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 18 Feb 2023 22:25:23 GMT
Subject: RFR: 8302525: Write a test to check various components send Events
 while mouse and key are used simultaneously
In-Reply-To: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
References: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
Message-ID: <W3ehaxVpgPTXy_m5uiK2qZH_aWxAYT0kFTdpygD5-h8=.1d120fd7-f837-4a34-981c-eb41aabcc8bd@github.com>

On Wed, 15 Feb 2023 12:50:42 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> Main aim of this testcase is to test the behavior of various events under stress.
> 
> This testcase verifies the following assertions
> a. This TestCase performs various mouse and key operations on components and checks whether all the events are getting triggered properly.
> b. It also checks some of the component specific events like item, action wherever necessary.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12571


From serb at openjdk.org  Sun Feb 19 09:25:29 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 19 Feb 2023 09:25:29 GMT
Subject: RFR: 8302268: Prefer ArrayList to LinkedList in XEmbeddedFramePeer
In-Reply-To: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
References: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
Message-ID: <UVeCzcRconDSsh1xZcxJ2ooxPpSgtmLfTrlqPqQBqC4=.020ef273-2276-4b74-a795-f7be067c8294@github.com>

On Thu, 9 Feb 2023 09:51:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator/indexOf calls on this list. No removes from the head or something like this. ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12486


From duke at openjdk.org  Sun Feb 19 09:35:53 2023
From: duke at openjdk.org (SWinxy)
Date: Sun, 19 Feb 2023 09:35:53 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>

> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
> 
> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
> 
> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
> 
> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
> 
> See also #6603, where this issue was discovered.

SWinxy 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:

 - BasicPanelUI uninstalling font causes cascading problems
 - Merge branch 'master' into 8278620
 - Sync with CSR
   
   Only difference is that I added an Oxford comma
 - Accidental imports added
 - 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled
   
   Many installDefaults methods set the font, foreground, and background on objects but their inverse methods uninstallDefaults do not remove them. I've added an inverse method to remove the colors and font to call for the uninstallDefaults methods that install defaults.
   
   AquaButtonUI can call its super since it would otherwise be repeated code. BasicComboBoxUI (weirdly) installs the properties again when it should be uninstalling them, so I changed.
   
   I noticed that, in a few subclasses, only one of calls to the super of installDefaults and uninstallDefaults are made. That is, an overridden installDefaults may call its super while the overridden uninstallDefaults does not call its super (or vise versa). These classes are: AquaTabbedPaneUI, SynthMenuItemUI, SynthSplitPaneUI, and XTextAreaPeer.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10565/files
  - new: https://git.openjdk.org/jdk/pull/10565/files/009855eb..1939190c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=01-02

  Stats: 529603 lines in 8460 files changed: 259868 ins; 165030 del; 104705 mod
  Patch: https://git.openjdk.org/jdk/pull/10565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10565/head:pull/10565

PR: https://git.openjdk.org/jdk/pull/10565


From duke at openjdk.org  Sun Feb 19 09:45:30 2023
From: duke at openjdk.org (SWinxy)
Date: Sun, 19 Feb 2023 09:45:30 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
Message-ID: <RxJb1i9B_hNUEP4HCbYzs0vJ-mbcdS3cXluoPoTxUk0=.7b3a5519-c61e-4479-80d6-bcfc8f8013b5@github.com>

On Sun, 19 Feb 2023 09:35:53 GMT, SWinxy <duke at openjdk.org> wrote:

>> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
>> 
>> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>> 
>> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
>> 
>> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
>> 
>> See also #6603, where this issue was discovered.
>
> SWinxy 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:
> 
>  - BasicPanelUI uninstalling font causes cascading problems
>  - Merge branch 'master' into 8278620
>  - Sync with CSR
>    
>    Only difference is that I added an Oxford comma
>  - Accidental imports added
>  - 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled
>    
>    Many installDefaults methods set the font, foreground, and background on objects but their inverse methods uninstallDefaults do not remove them. I've added an inverse method to remove the colors and font to call for the uninstallDefaults methods that install defaults.
>    
>    AquaButtonUI can call its super since it would otherwise be repeated code. BasicComboBoxUI (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>    
>    I noticed that, in a few subclasses, only one of calls to the super of installDefaults and uninstallDefaults are made. That is, an overridden installDefaults may call its super while the overridden uninstallDefaults does not call its super (or vise versa). These classes are: AquaTabbedPaneUI, SynthMenuItemUI, SynthSplitPaneUI, and XTextAreaPeer.

Found ? the ? problem! Removing the font from the JPanel causes a cascade of other components not getting the correct font objects when the component tree is updated. That is, the second time the font is installed, it is somehow different. In `BasicPanelUI#uninstallDefaults`, I've replaced `uninstallColorsAndFont` with `uninstallColors` for now. I've tested the two tests that Alexey said fail, and they both work again.
The components that don't receive the correct font are `JLabel`, `JButton`, `JMenuItem`, `JList`, `JComboBox`, `JToolTip`, and `JSpinner`. Figuring out what is causing *that* is not for almost-5AM-me. ?

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

PR: https://git.openjdk.org/jdk/pull/10565


From jwaters at openjdk.org  Sun Feb 19 11:50:38 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 19 Feb 2023 11:50:38 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
Message-ID: <x4lsMj2c6p8PUl3FCJzaTA3THa4yH9taFWFIygQKstM=.33dcb3ae-c293-4353-a0aa-7bbe00c64e4c@github.com>

On Sun, 19 Feb 2023 09:35:53 GMT, SWinxy <duke at openjdk.org> wrote:

>> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
>> 
>> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>> 
>> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
>> 
>> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
>> 
>> See also #6603, where this issue was discovered.
>
> SWinxy 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:
> 
>  - BasicPanelUI uninstalling font causes cascading problems
>  - Merge branch 'master' into 8278620
>  - Sync with CSR
>    
>    Only difference is that I added an Oxford comma
>  - Accidental imports added
>  - 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled
>    
>    Many installDefaults methods set the font, foreground, and background on objects but their inverse methods uninstallDefaults do not remove them. I've added an inverse method to remove the colors and font to call for the uninstallDefaults methods that install defaults.
>    
>    AquaButtonUI can call its super since it would otherwise be repeated code. BasicComboBoxUI (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>    
>    I noticed that, in a few subclasses, only one of calls to the super of installDefaults and uninstallDefaults are made. That is, an overridden installDefaults may call its super while the overridden uninstallDefaults does not call its super (or vise versa). These classes are: AquaTabbedPaneUI, SynthMenuItemUI, SynthSplitPaneUI, and XTextAreaPeer.

Heh, stuff like this happens much too often when you work on the JDK ;)

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

PR: https://git.openjdk.org/jdk/pull/10565


From duke at openjdk.org  Sun Feb 19 23:59:13 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sun, 19 Feb 2023 23:59:13 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs an
 improved scheme
Message-ID: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>

This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.

The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:

void forEachRemaining(Consumer<? super Integer> action);
void forEachRemaining(IntConsumer action);

Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:

    spliterator.forEachRemaining(x -> { ... });

That code won't compile; instead, you'll get this error:

Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
        spliterator.forEachRemaining(x -> { });
                   ^
  both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match


The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:

interface ConsumerOfInteger {
    void foo(Consumer<Integer> c);
}

interface IntegerConsumer {
    void foo(IntConsumer c);
}

// We should get a warning here...
interface Test extends ConsumerOfInteger, IntegerConsumer {
}


The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.

To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.

So we generate the warning when there are two methods m1 and m2 in a class C such that:

* m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
* There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
* We haven't already generated a warning for either m1 or m2 in class C

If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.

I noticed a couple of other minor bugs; these are also being fixed here:

(1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:

interface Upper<T> {
    void foo(T c);
}

interface Lower extends Upper<IntConsumer> {
    void foo(Consumer<Integer> c);
}

Currently, the error is reported as:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper

Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:

warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper


(2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.

As a result, for a class like the one below, the compiler was only generating one warning instead of three:

public interface SuperIface {
    void foo(Consumer<Integer> c);
}

public interface I1 extends SuperIface { 
    void foo(IntConsumer c);        // warning was generated here
}   

public interface I2 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   

public interface I3 extends SuperIface { 
    void foo(IntConsumer c);        // no warning was generated here
}   


With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.

Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

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

Commit messages:
 - Fix incomplete detection of potentially ambiguous method declarations.

Changes: https://git.openjdk.org/jdk/pull/12645/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12645&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8026369
  Stats: 356 lines in 18 files changed: 280 ins; 36 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/12645.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12645/head:pull/12645

PR: https://git.openjdk.org/jdk/pull/12645


From duke at openjdk.org  Mon Feb 20 05:47:45 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Mon, 20 Feb 2023 05:47:45 GMT
Subject: RFR: 8302525: Write a test to check various components send Events
 while mouse and key are used simultaneously [v2]
In-Reply-To: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
References: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
Message-ID: <2fg14NB8zhvyx__eeSyZHilFD0FN8CVc2OJHMNBnzFo=.2a146158-310c-4e4f-9af6-2fa5444de7ad@github.com>

> Main aim of this testcase is to test the behavior of various events under stress.
> 
> This testcase verifies the following assertions
> a. This TestCase performs various mouse and key operations on components and checks whether all the events are getting triggered properly.
> b. It also checks some of the component specific events like item, action wherever necessary.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

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

  8302525: Review Fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12571/files
  - new: https://git.openjdk.org/jdk/pull/12571/files/07fb520a..170d90ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12571&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12571&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12571


From tr at openjdk.org  Mon Feb 20 07:13:20 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Feb 2023 07:13:20 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v13]
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <3eF6RDDO22GhOXulkEh8xaT8p8nhu9yxxj0-wHYH7oo=.2f05c039-d3b7-4bb2-a658-e61d5e10caa6@github.com>

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

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

 - Copyright update
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8299522
 - Remove unused imports
 - Tooltip and Mnemonic checks added to test
 - Updated JTREG summary
 - Added Aqua L&F -  linked to #12008 fix
 - Updated based on review comments
 - Updated based on review comments
 - Updated based on review comments
 - Spacing updation
 - ... and 4 more: https://git.openjdk.org/jdk/compare/08eddab8...0ca14f69

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11901/files
  - new: https://git.openjdk.org/jdk/pull/11901/files/8c3d5c00..0ca14f69

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11901&range=11-12

  Stats: 125478 lines in 4204 files changed: 54798 ins; 29112 del; 41568 mod
  Patch: https://git.openjdk.org/jdk/pull/11901.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11901/head:pull/11901

PR: https://git.openjdk.org/jdk/pull/11901


From duke at openjdk.org  Mon Feb 20 08:12:03 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 20 Feb 2023 08:12:03 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v4]
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <UIeyryZ87HqLgir1s8Y8Ly3EkR-utVcj5gKZ1N6Znr4=.e93aa632-8ce7-4f38-b11a-ed4ef2227b3d@github.com>

> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
> 
> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
> 
> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
> 
> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
> 
> See also #6603, where this issue was discovered.

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

 - Make default fonts FontUIResources
 - Minor cleanup on StalePreferredSize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10565/files
  - new: https://git.openjdk.org/jdk/pull/10565/files/1939190c..1cc42222

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=02-03

  Stats: 75 lines in 5 files changed: 19 ins; 37 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/10565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10565/head:pull/10565

PR: https://git.openjdk.org/jdk/pull/10565


From duke at openjdk.org  Mon Feb 20 08:12:10 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 20 Feb 2023 08:12:10 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
Message-ID: <CUV8tTI9usmM4UwWWHh1H5g8V81MlfrtlEkU4_kJVIE=.3515d3c6-8859-4024-bb1a-cc63d6aca7ec@github.com>

On Sun, 19 Feb 2023 09:35:53 GMT, SWinxy <duke at openjdk.org> wrote:

>> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
>> 
>> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>> 
>> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
>> 
>> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
>> 
>> See also #6603, where this issue was discovered.
>
> SWinxy 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:
> 
>  - BasicPanelUI uninstalling font causes cascading problems
>  - Merge branch 'master' into 8278620
>  - Sync with CSR
>    
>    Only difference is that I added an Oxford comma
>  - Accidental imports added
>  - 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled
>    
>    Many installDefaults methods set the font, foreground, and background on objects but their inverse methods uninstallDefaults do not remove them. I've added an inverse method to remove the colors and font to call for the uninstallDefaults methods that install defaults.
>    
>    AquaButtonUI can call its super since it would otherwise be repeated code. BasicComboBoxUI (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>    
>    I noticed that, in a few subclasses, only one of calls to the super of installDefaults and uninstallDefaults are made. That is, an overridden installDefaults may call its super while the overridden uninstallDefaults does not call its super (or vise versa). These classes are: AquaTabbedPaneUI, SynthMenuItemUI, SynthSplitPaneUI, and XTextAreaPeer.

Figured it out. When setting a `Component`'s font to `null`, it inherits the font from the component tree. (Some classes omit this fact from their respective documentations.) Window peers will check `isFontSet` when they are created, and will set it to a `Font` if no font is set. The problem is that installing the font checks if the font is critically a `FontUIResource`. This means that `setFont(null)` is called on `FontUIResource` fonts, the code goes up the hierarchy to non-null fonts, and finds a non-`FontUIResource` font, and sets the component to that font, which is originally set by the component peers on creation, and then the components can't install a default because it will replace a `null` or a `FontUIResource` font. Changing the fallback font type to a `FontUIResource` in the peers fixes this. I hope this doesn't break anything else lol. (It probably will.)

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

PR: https://git.openjdk.org/jdk/pull/10565


From jwaters at openjdk.org  Mon Feb 20 08:17:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 20 Feb 2023 08:17:12 GMT
Subject: RFR: 8302838: jabswitch main() should avoid calling exit explicitly
Message-ID: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>

In jabswitch, main is defined as `void main()`, which requires an explicit exit call whenever an error occurs, and extra error checking code on our part. Visual C++ will automatically convert all instances of `void main()` to return 0 in all cases anyway, and there isn't anything gained from using this custom signature when the same can be achieved by simply returning the error value normally, so I propose we simply change it to the regular `int main` signature

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

Commit messages:
 - jabswitch.cpp

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

PR: https://git.openjdk.org/jdk/pull/12650


From psadhukhan at openjdk.org  Mon Feb 20 08:22:42 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Feb 2023 08:22:42 GMT
Subject: Integrated: 6753661: JFileChooser font not reset after Look & Feel
 change
In-Reply-To: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
References: <w-AjmK7sVwQY_KaMub0YefJj4ksyVi5hyqPE3dNGsG4=.e042ec6b-223a-4b80-8a20-cc356fe46dcc@github.com>
Message-ID: <j6n_EAfsCZulLmbuv_GhCUJk3GkGq1y3YjU66tY1i6c=.11dec47c-fff7-4ae4-abcd-02bff46b24ec@github.com>

On Wed, 25 Jan 2023 06:45:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is observed that after changing the Look & Feel from Metal to Nimbus and back to Metal, the Nimbus font continues to be used by a JFileChooser.
> This is because Synth  `installDefaults `methods set the font, but its inverse methods `uninstallDefaults `do not remove them.
> Fix is made to reset the font if it is set by L&F.

This pull request has now been integrated.

Changeset: 432cf68c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/432cf68c4dd1dcce478fccb85163aa0d824474d7
Stats:     84 lines in 2 files changed: 84 ins; 0 del; 0 mod

6753661: JFileChooser font not reset after Look & Feel change

Reviewed-by: abhiscxk, aivanov, serb

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

PR: https://git.openjdk.org/jdk/pull/12180


From jdv at openjdk.org  Mon Feb 20 09:37:29 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 20 Feb 2023 09:37:29 GMT
Subject: RFR: 8302151: BMPImageReader throws an exception reading BMP
 images
In-Reply-To: <8Ct2eSCf6q_6wxerg_QBbEza1AkwwAQJobHQ1Zw34XA=.d40c87c9-9bb3-485d-8a90-82f7b590cb87@github.com>
References: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
 <8Ct2eSCf6q_6wxerg_QBbEza1AkwwAQJobHQ1Zw34XA=.d40c87c9-9bb3-485d-8a90-82f7b590cb87@github.com>
Message-ID: <s2_JHwwe273ggXs_Gfphha7p7aWX7IrL2tzoi4WIL9g=.6ec264b0-fa23-4867-8f67-dfbcdf14d1b8@github.com>

On Wed, 15 Feb 2023 23:20:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> We have check in BMPImageReader, where we verify image data size using BMP file size and bitmap offset value.
>> But we can't rely on this calculation when we have color palette. Also color palette is necessary in BMP when bits per pixel is less than 16 according to BMP specification(https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header).
>> 
>> Now extra checks are added to not perform this check when we have color palette or bpp is less than 16.
>> 
>> Also when bitsPerPixel was less than 8 it was getting down-casted to 0. So this is also resolved by making this check for >=16bpp and not doing (bitsPerPixel / 8)
>
> src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageReader.java line 596:
> 
>> 594: 
>> 595:         if (metadata.compression == BI_RGB &&
>> 596:             metadata.paletteSize == 0 &&
> 
> Do we validate the "metadata.paletteSize" in all code paths above or it can be substituted to have the wrong value(do we actually trust it)?

We read color palette using ReaderUtil.staggeredReadByteStream() at all places to make sure we will not end up in OOME situations. So we can say that paletteSize parameter is well protected.

In general, we can't verify checks for all the parameters of header in a stream. This just adds more verification to overcome the regression introduced for reading lower bpp images.

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

PR: https://git.openjdk.org/jdk/pull/12573


From pminborg at openjdk.org  Mon Feb 20 10:33:01 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 20 Feb 2023 10:33:01 GMT
Subject: RFR: 8302849: SurfaceManager might expose partially constructed object
Message-ID: <Ppas5MKQoxJHK8icV5-hsTlihbeF-47uwx2mrtIwB-g=.196f6cc9-4b0e-49a4-9e36-f629d47f0175@github.com>

This PR proposes to add `volatile` to a variable declaration in order to prevent partially initialized objects to be observed by threads.

`SurfaceManager` is using a lazily initialized cacheMap that is initialized using a double-checked locking mechanism. Generally, objects initialized using such constructs need to be declared volatile. 

See https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java

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

Commit messages:
 - Prevent partially constructed object to be observed

Changes: https://git.openjdk.org/jdk/pull/12654/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12654&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302849
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12654.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12654/head:pull/12654

PR: https://git.openjdk.org/jdk/pull/12654


From duke at openjdk.org  Mon Feb 20 13:46:27 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Mon, 20 Feb 2023 13:46:27 GMT
Subject: RFR: 8302525: Write a test to check various components send Events
 while mouse and key are used simultaneously [v2]
In-Reply-To: <W3ehaxVpgPTXy_m5uiK2qZH_aWxAYT0kFTdpygD5-h8=.1d120fd7-f837-4a34-981c-eb41aabcc8bd@github.com>
References: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
 <W3ehaxVpgPTXy_m5uiK2qZH_aWxAYT0kFTdpygD5-h8=.1d120fd7-f837-4a34-981c-eb41aabcc8bd@github.com>
Message-ID: <hrZ0xO2DHXs4MMjhduLCUQAW_uVGo7kxxRLX5sW_NKs=.101e7ec2-63c7-4f01-bf22-61f1057ca01e@github.com>

On Sat, 18 Feb 2023 22:22:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Ravi Gupta has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8302525: Review Fixes
>
> Marked as reviewed by serb (Reviewer).

@mrserb requesting you to please sponsor.

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

PR: https://git.openjdk.org/jdk/pull/12571


From aivanov at openjdk.org  Mon Feb 20 14:43:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Feb 2023 14:43:52 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v13]
In-Reply-To: <3eF6RDDO22GhOXulkEh8xaT8p8nhu9yxxj0-wHYH7oo=.2f05c039-d3b7-4bb2-a658-e61d5e10caa6@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <3eF6RDDO22GhOXulkEh8xaT8p8nhu9yxxj0-wHYH7oo=.2f05c039-d3b7-4bb2-a658-e61d5e10caa6@github.com>
Message-ID: <mAc0zG6FXw4rStTpxK40kwYXYOjAwoEZcDNCIAM_jD0=.9c3b09ef-56b9-4c7c-8b0c-8e7a10343961@github.com>

On Mon, 20 Feb 2023 07:13:20 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Copyright update
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8299522
>  - Remove unused imports
>  - Tooltip and Mnemonic checks added to test
>  - Updated JTREG summary
>  - Added Aqua L&F -  linked to #12008 fix
>  - Updated based on review comments
>  - Updated based on review comments
>  - Updated based on review comments
>  - Spacing updation
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/3fa881e9...0ca14f69

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/11901


From psadhukhan at openjdk.org  Mon Feb 20 14:51:20 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Feb 2023 14:51:20 GMT
Subject: Integrated: 8302882: Newly added test
 javax/swing/JFileChooser/JFileChooserFontReset.java fails with
 HeadlessException
Message-ID: <bx23nj2QVyr9ZBwmQgonfF4aZu1GS1a1Tw6X4wRcGyY=.ecd7bdcc-21fa-4f63-9703-d488e3baad9c@github.com>

Added key headful to the test

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

Commit messages:
 - 8302882: Newly added test javax/swing/JFileChooser/JFileChooserFontReset.java fails with HeadlessException

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

PR: https://git.openjdk.org/jdk/pull/12666


From jdv at openjdk.org  Mon Feb 20 14:51:21 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 20 Feb 2023 14:51:21 GMT
Subject: Integrated: 8302882: Newly added test
 javax/swing/JFileChooser/JFileChooserFontReset.java fails with
 HeadlessException
In-Reply-To: <bx23nj2QVyr9ZBwmQgonfF4aZu1GS1a1Tw6X4wRcGyY=.ecd7bdcc-21fa-4f63-9703-d488e3baad9c@github.com>
References: <bx23nj2QVyr9ZBwmQgonfF4aZu1GS1a1Tw6X4wRcGyY=.ecd7bdcc-21fa-4f63-9703-d488e3baad9c@github.com>
Message-ID: <6LjRYqhNBGPoFP4hiaYeuJz_M1hfjj5ZnmificzOBek=.c183a647-2a63-46d9-b0f3-79c50ff9adc9@github.com>

On Mon, 20 Feb 2023 14:38:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Added key headful to the test

Marked as reviewed by jdv (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12666


From psadhukhan at openjdk.org  Mon Feb 20 14:51:22 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Feb 2023 14:51:22 GMT
Subject: Integrated: 8302882: Newly added test
 javax/swing/JFileChooser/JFileChooserFontReset.java fails with
 HeadlessException
In-Reply-To: <bx23nj2QVyr9ZBwmQgonfF4aZu1GS1a1Tw6X4wRcGyY=.ecd7bdcc-21fa-4f63-9703-d488e3baad9c@github.com>
References: <bx23nj2QVyr9ZBwmQgonfF4aZu1GS1a1Tw6X4wRcGyY=.ecd7bdcc-21fa-4f63-9703-d488e3baad9c@github.com>
Message-ID: <mink8IvTYQwC6Wonc_9bGlc8mpE--3EpKb3ZYkTSB4U=.dcd4b937-11d3-43b1-87a1-fd3f4668eb4b@github.com>

On Mon, 20 Feb 2023 14:38:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Added key headful to the test

This pull request has now been integrated.

Changeset: e7316952
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e731695217b75fd55dc3e820c3123b8739a19c04
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8302882: Newly added test javax/swing/JFileChooser/JFileChooserFontReset.java fails with HeadlessException

Reviewed-by: jdv

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

PR: https://git.openjdk.org/jdk/pull/12666


From aivanov at openjdk.org  Mon Feb 20 15:07:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Feb 2023 15:07:39 GMT
Subject: Integrated: 8302882: Newly added test
 javax/swing/JFileChooser/JFileChooserFontReset.java fails with
 HeadlessException
In-Reply-To: <bx23nj2QVyr9ZBwmQgonfF4aZu1GS1a1Tw6X4wRcGyY=.ecd7bdcc-21fa-4f63-9703-d488e3baad9c@github.com>
References: <bx23nj2QVyr9ZBwmQgonfF4aZu1GS1a1Tw6X4wRcGyY=.ecd7bdcc-21fa-4f63-9703-d488e3baad9c@github.com>
Message-ID: <PkLCUAqFc8BOC2f-hIlEec6KFFhmnYfm-o5ay4vZjuY=.67433659-0ed1-4eb5-9957-50e891e5ed7d@github.com>

On Mon, 20 Feb 2023 14:38:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Added key headful to the test

test/jdk/javax/swing/JFileChooser/JFileChooserFontReset.java line 25:

> 23: /*
> 24:  * @test
> 25:  * @bug 6753661 8302882

8302882 shouldn't have been added to bug list. [JDK-8302882](https://bugs.openjdk.org/browse/JDK-8302882) is a test bug. See the [Developer's Guide](https://openjdk.org/guide/#testing-the-jdk): ?JBS issues that track changes to the test itself are not listed here.?

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

PR: https://git.openjdk.org/jdk/pull/12666


From abhiscxk at openjdk.org  Mon Feb 20 15:55:39 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 20 Feb 2023 15:55:39 GMT
Subject: RFR: 8299522: Incorrect size of Approve button in custom
 JFileChooser [v13]
In-Reply-To: <3eF6RDDO22GhOXulkEh8xaT8p8nhu9yxxj0-wHYH7oo=.2f05c039-d3b7-4bb2-a658-e61d5e10caa6@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
 <3eF6RDDO22GhOXulkEh8xaT8p8nhu9yxxj0-wHYH7oo=.2f05c039-d3b7-4bb2-a658-e61d5e10caa6@github.com>
Message-ID: <CMLPqssiGV1g8PzyEi5LyNcVdYkejntkXjw1vd9HdL8=.8c17740c-d198-4c26-b74a-01896539e144@github.com>

On Mon, 20 Feb 2023 07:13:20 GMT, Tejesh R <tr at openjdk.org> wrote:

>> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
>> Automated test is attached which has been tested with multiple test runs.
>
> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Copyright update
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8299522
>  - Remove unused imports
>  - Tooltip and Mnemonic checks added to test
>  - Updated JTREG summary
>  - Added Aqua L&F -  linked to #12008 fix
>  - Updated based on review comments
>  - Updated based on review comments
>  - Updated based on review comments
>  - Spacing updation
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/de506664...0ca14f69

Test verified.

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

Marked as reviewed by abhiscxk (Committer).

PR: https://git.openjdk.org/jdk/pull/11901


From serb at openjdk.org  Mon Feb 20 18:23:25 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Feb 2023 18:23:25 GMT
Subject: RFR: 8302849: SurfaceManager might expose partially constructed
 object
In-Reply-To: <Ppas5MKQoxJHK8icV5-hsTlihbeF-47uwx2mrtIwB-g=.196f6cc9-4b0e-49a4-9e36-f629d47f0175@github.com>
References: <Ppas5MKQoxJHK8icV5-hsTlihbeF-47uwx2mrtIwB-g=.196f6cc9-4b0e-49a4-9e36-f629d47f0175@github.com>
Message-ID: <x49GcOOFfmPYrc3VgSWeqDUI54J9rPbo7p2lKW9DQeI=.1db9c35a-672e-45a2-80f3-7c2c939512c2@github.com>

On Mon, 20 Feb 2023 10:25:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add `volatile` to a variable declaration in order to prevent partially initialized objects to be observed by threads.
> 
> `SurfaceManager` is using a lazily initialized cacheMap that is initialized using a double-checked locking mechanism. Generally, objects initialized using such constructs need to be declared volatile. 
> 
> See https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12654


From serb at openjdk.org  Mon Feb 20 18:26:24 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 20 Feb 2023 18:26:24 GMT
Subject: RFR: 8302151: BMPImageReader throws an exception reading BMP
 images
In-Reply-To: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
References: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
Message-ID: <2-59eRCEAlV5LcHjeArayX7I0V-EwSmww_lKdAT4ZjI=.590ee600-e7a8-451c-828f-4fa5aa1f68c0@github.com>

On Wed, 15 Feb 2023 13:18:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have check in BMPImageReader, where we verify image data size using BMP file size and bitmap offset value.
> But we can't rely on this calculation when we have color palette. Also color palette is necessary in BMP when bits per pixel is less than 16 according to BMP specification(https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header).
> 
> Now extra checks are added to not perform this check when we have color palette or bpp is less than 16.
> 
> Also when bitsPerPixel was less than 8 it was getting down-casted to 0. So this is also resolved by making this check for >=16bpp and not doing (bitsPerPixel / 8)

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12573


From duke at openjdk.org  Mon Feb 20 18:35:39 2023
From: duke at openjdk.org (Ravi Gupta)
Date: Mon, 20 Feb 2023 18:35:39 GMT
Subject: Integrated: 8302525: Write a test to check various components send
 Events while mouse and key are used simultaneously
In-Reply-To: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
References: <6Y-nCQVoQbilhaZal0n134kQSNb8-ynunvMThh_9S4I=.aefe15d5-4bca-4e03-8197-f7e771abdef8@github.com>
Message-ID: <5-C9hGN5u_AqVkqHLbyFdVAc-qGzC4m8x03UJ7n7MKQ=.c351c983-ef79-4797-a88e-f189502f7797@github.com>

On Wed, 15 Feb 2023 12:50:42 GMT, Ravi Gupta <duke at openjdk.org> wrote:

> Main aim of this testcase is to test the behavior of various events under stress.
> 
> This testcase verifies the following assertions
> a. This TestCase performs various mouse and key operations on components and checks whether all the events are getting triggered properly.
> b. It also checks some of the component specific events like item, action wherever necessary.
> 
> Testing:
> Tested using Mach5(20 times per platform) in macos,linux and windows and got all pass.

This pull request has now been integrated.

Changeset: c7517b3d
Author:    ravi.ra.gupta <ravi.ra.gupta at oracle.com>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7517b3decdc55edb7f0ce6e6aa09a6b653c747d
Stats:     556 lines in 1 file changed: 556 ins; 0 del; 0 mod

8302525: Write a test to check various components send Events while mouse and key are used simultaneously

Reviewed-by: serb

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

PR: https://git.openjdk.org/jdk/pull/12571


From duke at openjdk.org  Mon Feb 20 23:20:25 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 20 Feb 2023 23:20:25 GMT
Subject: RFR: 8302838: jabswitch main() should avoid calling exit
 explicitly
In-Reply-To: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>
References: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>
Message-ID: <iZhL_0zdzTE6USZLRmr5VcTwfzDTRBaDKYQ8lw9HjDs=.08feb74a-419d-43b3-bdc0-6271ba0e980c@github.com>

On Mon, 20 Feb 2023 08:10:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In jabswitch, main is defined as `void main()`, which requires an explicit exit call whenever an error occurs, and extra error checking code on our part. Visual C++ will automatically convert all instances of `void main()` to return 0 in all cases anyway, and there isn't anything gained from using this custom signature when the same can be achieved by simply returning the error value normally, so I propose we simply change it to the regular `int main` signature

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/12650


From duke at openjdk.org  Mon Feb 20 23:55:24 2023
From: duke at openjdk.org (SWinxy)
Date: Mon, 20 Feb 2023 23:55:24 GMT
Subject: RFR: 8026369: javac potentially ambiguous overload warning needs
 an improved scheme
In-Reply-To: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
References: <IMxp3iCK--jYJ5Ia04i6QPYfnCHQobVcsmlI5aJXdqc=.892abcb8-7f2a-4fe9-aea2-1b1d41098a6d@github.com>
Message-ID: <xVTkB9-V5fVop5Mix7Gk29Ix3JCtAlBZeHR-064qaw0=.b3e9d5c2-4def-4410-8a59-c8c25049f7e4@github.com>

On Sun, 19 Feb 2023 23:52:52 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug relates to the "potentially ambiguous overload" warning which is enabled by `-Xlint:overloads`.
> 
> The warning detects certain ambiguities that can cause problems for lambdas. For example, consider the interface `Spliterator.OfInt`, which declares these two methods:
> 
> void forEachRemaining(Consumer<? super Integer> action);
> void forEachRemaining(IntConsumer action);
> 
> Both methods have the same name, same number of parameters, and take a lambda with the same "shape" in the same argument position. This causes an ambiguity in any code that wants to do this:
> 
>     spliterator.forEachRemaining(x -> { ... });
> 
> That code won't compile; instead, you'll get this error:
> 
> Ambiguity.java:4: error: reference to forEachRemaining is ambiguous
>         spliterator.forEachRemaining(x -> { });
>                    ^
>   both method forEachRemaining(IntConsumer) in OfInt and method forEachRemaining(Consumer<? super Integer>) in OfInt match
> 
> 
> The problem reported by the bug is that the warning fails to detect ambiguities which are created purely by inheritance, for example:
> 
> interface ConsumerOfInteger {
>     void foo(Consumer<Integer> c);
> }
> 
> interface IntegerConsumer {
>     void foo(IntConsumer c);
> }
> 
> // We should get a warning here...
> interface Test extends ConsumerOfInteger, IntegerConsumer {
> }
> 
> 
> The cause of the bug is that ambiguities are detected on a per-method basis, by checking whether a method is part of an ambiguity pair when we visit that method. So if the methods in an ambiguity pair are inherited from two distinct supertypes, we'll miss the ambiguity.
> 
> To fix the problem, we need to look for ambiguities on a per-class level, checking all pairs of methods. However, it's not that simple - we only want to "blame" a class when that class itself, and not some supertype, is responsible for creating the ambiguity. For example, any interface extending `Spliterator.OfInt` will automatically inherit the two ambiguities mentioned above, but these are not the interface's fault so to speak so no warning should be generated. Making things more complicated is the fact that methods can be overridden and declared in generic classes so they only conflict in some subtypes, etc.
> 
> So we generate the warning when there are two methods m1 and m2 in a class C such that:
> 
> * m1 and m2 consitiute a "potentially ambiguous overload" (using the same definition as before)
> * There is no direct supertype T of C such that m1 and m2, or some methods they override, both exist in T and constitute a "potentially ambiguous overload" as members of T
> * We haven't already generated a warning for either m1 or m2 in class C
> 
> If either method is declared in C, we locate the warning there, but when both methods are inherited, there's no method declaration to point at so the warning is instead located at the class declaration.
> 
> I noticed a couple of other minor bugs; these are also being fixed here:
> 
> (1) For inherited methods, the method signatures were being reported as they are declared, rather than in the context of the class being visited. As a result, when a methods is inherited from a generic supertype, the ambiguity is less clear. Here's an example:
> 
> interface Upper<T> {
>     void foo(T c);
> }
> 
> interface Lower extends Upper<IntConsumer> {
>     void foo(Consumer<Integer> c);
> }
> 
> Currently, the error is reported as:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(T) in Upper
> 
> Reporting the method signatures in the context of the class being visited makes the ambiguity clearer:
> 
> warning: [overloads] foo(Consumer<Integer>) in Lower is potentially ambiguous with foo(IntConsumer) in Upper
> 
> 
> (2) When a method is identified as part of an ambiguous pair, we were setting a `POTENTIALLY_AMBIGUOUS` flag on it. This caused it to be forever excluded from future warnings. For methods that are declared in the class we're visiting, this makes sense, but it doesn't make sense for inherited methods, because it disqualifies them from participating in the analysis of any other class that also inherits them.
> 
> As a result, for a class like the one below, the compiler was only generating one warning instead of three:
> 
> public interface SuperIface {
>     void foo(Consumer<Integer> c);
> }
> 
> public interface I1 extends SuperIface { 
>     void foo(IntConsumer c);        // warning was generated here
> }   
> 
> public interface I2 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> public interface I3 extends SuperIface { 
>     void foo(IntConsumer c);        // no warning was generated here
> }   
> 
> 
> With this patch the `POTENTIALLY_AMBIGUOUS` flag is no longer needed. I wasn't sure whether to renumber all the subsequent flags, or just leave an empty placeholder, so I chose the latter.
> 
> Finally, this fix uncovers new warnings in `java.base` and `java.desktop`, so these are now suppressed in the patch.

In the `AWTEventMulticaster` class(es), which interfaces are causing the ambiguity?

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

PR: https://git.openjdk.org/jdk/pull/12645


From tr at openjdk.org  Tue Feb 21 05:22:45 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Feb 2023 05:22:45 GMT
Subject: Integrated: 8299522: Incorrect size of Approve button in custom
 JFileChooser
In-Reply-To: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
References: <PZ_b_X_txqKAxh8mTNboG-xMiWYu5Y6AU4ihgdSzMXE=.a2d686b1-40d0-4780-b914-184711178e64@github.com>
Message-ID: <AK-5subinQq2HUVZJTcm9PM2ufyQifPiLUBrawSVTmQ=.1b8df0fa-da4d-4823-9a26-f49dac7ee45c@github.com>

On Mon, 9 Jan 2023 10:24:49 GMT, Tejesh R <tr at openjdk.org> wrote:

> FileChooser Open/Approve button size is shown incorrectly when no Approve button text is set in `CUSTOM_DIALOG` type. Reason being that no default Approve Button text is returned during Dialog Type Property change. Since `null` is returned as Button string the Button size is incorrectly shown. The fix here addresses the issue by adding a default Approve Button Text when no text is set explicitly in case of `CUSTOM_DIALOG` type.
> Automated test is attached which has been tested with multiple test runs.

This pull request has now been integrated.

Changeset: 29f392e4
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29f392e4344e467882c36b5737d432b2d0ee7ebb
Stats:     109 lines in 2 files changed: 103 ins; 0 del; 6 mod

8299522: Incorrect size of Approve button in custom JFileChooser

Reviewed-by: aivanov, abhiscxk, dnguyen

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

PR: https://git.openjdk.org/jdk/pull/11901


From tr at openjdk.org  Tue Feb 21 06:48:24 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Feb 2023 06:48:24 GMT
Subject: RFR: 8302151: BMPImageReader throws an exception reading BMP
 images
In-Reply-To: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
References: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
Message-ID: <lEhHDbs_F7S5LInbvXr8qiiau2NY8OB98WVjpaabbOU=.3f10c75e-f04e-447b-b49e-1c6f9b2958ff@github.com>

On Wed, 15 Feb 2023 13:18:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have check in BMPImageReader, where we verify image data size using BMP file size and bitmap offset value.
> But we can't rely on this calculation when we have color palette. Also color palette is necessary in BMP when bits per pixel is less than 16 according to BMP specification(https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header).
> 
> Now extra checks are added to not perform this check when we have color palette or bpp is less than 16.
> 
> Also when bitsPerPixel was less than 8 it was getting down-casted to 0. So this is also resolved by making this check for >=16bpp and not doing (bitsPerPixel / 8)

Fix verified.

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

Marked as reviewed by tr (Committer).

PR: https://git.openjdk.org/jdk/pull/12573


From jdv at openjdk.org  Tue Feb 21 07:33:41 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 21 Feb 2023 07:33:41 GMT
Subject: Integrated: 8302151: BMPImageReader throws an exception reading BMP
 images
In-Reply-To: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
References: <WY7f-J8YOYY0mzxlV4zOwn-wfZMWkioVOO2Md9mc0hY=.b81b1da9-e2e2-44ae-ac62-bf769ac98435@github.com>
Message-ID: <HX5c_x4us7sjuwFkdroKVdEFCsJDBPeefuX1BICSoZc=.ac60adfe-da34-4adc-b47d-9498737728ea@github.com>

On Wed, 15 Feb 2023 13:18:31 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> We have check in BMPImageReader, where we verify image data size using BMP file size and bitmap offset value.
> But we can't rely on this calculation when we have color palette. Also color palette is necessary in BMP when bits per pixel is less than 16 according to BMP specification(https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-bitmapv4header).
> 
> Now extra checks are added to not perform this check when we have color palette or bpp is less than 16.
> 
> Also when bitsPerPixel was less than 8 it was getting down-casted to 0. So this is also resolved by making this check for >=16bpp and not doing (bitsPerPixel / 8)

This pull request has now been integrated.

Changeset: aa10f0d3
Author:    Jayathirth D V <jdv at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa10f0d3ee5d77d83950c9ed4aab11589b822ff4
Stats:     68 lines in 2 files changed: 66 ins; 0 del; 2 mod

8302151: BMPImageReader throws an exception reading BMP images

Reviewed-by: serb, tr

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

PR: https://git.openjdk.org/jdk/pull/12573


From jwaters at openjdk.org  Tue Feb 21 17:01:02 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Feb 2023 17:01:02 GMT
Subject: RFR: 8302838: jabswitch main() should avoid calling exit
 explicitly [v2]
In-Reply-To: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>
References: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>
Message-ID: <GzfbICweV7VQ990cG_h5LvNjnzfUlD5GDJdQ08LyCQ4=.9796d4e8-5413-4475-901e-0170792511e7@github.com>

> In jabswitch, main is defined as `void main()`, which requires an explicit exit call whenever an error occurs, and extra error checking code on our part. Visual C++ will automatically convert all instances of `void main()` to return 0 in all cases anyway, and there isn't anything gained from using this custom signature when the same can be achieved by simply returning the error value normally, so I propose we simply change it to the regular `int main` signature

Julian Waters 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 patch-8
 - jabswitch.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12650/files
  - new: https://git.openjdk.org/jdk/pull/12650/files/c5783d47..a04b8f51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12650&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12650&range=00-01

  Stats: 3652 lines in 172 files changed: 2273 ins; 939 del; 440 mod
  Patch: https://git.openjdk.org/jdk/pull/12650.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12650/head:pull/12650

PR: https://git.openjdk.org/jdk/pull/12650


From serb at openjdk.org  Tue Feb 21 22:17:27 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 21 Feb 2023 22:17:27 GMT
Subject: RFR: 8302838: jabswitch main() should avoid calling exit
 explicitly [v2]
In-Reply-To: <GzfbICweV7VQ990cG_h5LvNjnzfUlD5GDJdQ08LyCQ4=.9796d4e8-5413-4475-901e-0170792511e7@github.com>
References: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>
 <GzfbICweV7VQ990cG_h5LvNjnzfUlD5GDJdQ08LyCQ4=.9796d4e8-5413-4475-901e-0170792511e7@github.com>
Message-ID: <EM-3xesiFs2jdEfrLJdDjXJFvrz-uLuuow6fxMelBBE=.0af72e41-0873-4475-83a9-bbd66c7354ce@github.com>

On Tue, 21 Feb 2023 17:01:02 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> In jabswitch, main is defined as `void main()`, which requires an explicit exit call whenever an error occurs, and extra error checking code on our part. Visual C++ will automatically convert all instances of `void main()` to return 0 in all cases anyway, and there isn't anything gained from using this custom signature when the same can be achieved by simply returning the error value normally, so I propose we simply change it to the regular `int main` signature
>
> Julian Waters 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 patch-8
>  - jabswitch.cpp

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12650


From dnguyen at openjdk.org  Tue Feb 21 22:42:29 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Feb 2023 22:42:29 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v3]
In-Reply-To: <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Sats3-zFBrMYdEumFocp79OcCLfo0cIBdfmr3ZNESW0=.0d2e815b-0bba-4e36-9d06-a6def2a632eb@github.com>
Message-ID: <OYkIBpfmRT0SIV1nK5SxsX86tw5wDCOOy4FSrEWXlFQ=.a0489f6c-d373-415e-a797-d60907c1a901@github.com>

On Tue, 14 Feb 2023 02:29:16 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add instanceof check
>
> Changes requested by honkar (Committer).

@honkar-jdk Could you take another look at the changes?
@prsadhuk Could you also review this?

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

PR: https://git.openjdk.org/jdk/pull/12520


From duke at openjdk.org  Tue Feb 21 23:13:28 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 21 Feb 2023 23:13:28 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v3]
In-Reply-To: <Aid3vKSu2kPE3SGY2yvQntUi4cE8fOZmlJ5Y1bVz-Xs=.237ee245-302c-4426-b2b1-46ff7bbdcb46@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Aid3vKSu2kPE3SGY2yvQntUi4cE8fOZmlJ5Y1bVz-Xs=.237ee245-302c-4426-b2b1-46ff7bbdcb46@github.com>
Message-ID: <seLyBDV5c8IqeRPkI3hyYz6kOmosatntZoM-RuezYj8=.2a90c730-3c9c-4efb-8318-0af2dd74e9a6@github.com>

On Tue, 14 Feb 2023 23:02:16 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
>> 
>> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
>> 
>> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add instanceof check

Changes requested by SWinxy at github.com (no known OpenJDK username).

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 344:

> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
> 343:         if (v != null && c instanceof AbstractButton
> 344:                 && ((AbstractButton) c).getIcon() == null) {

We already know for certain that `c` is an AbstractButton. The first thing in the paint call, the component is casted. Why cast again when we can reuse the variable:
Suggestion:

        if (v != null && b.getIcon() == null) {


(also on ln 309 we could do the same thing)

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Wed Feb 22 00:02:14 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Feb 2023 00:02:14 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v3]
In-Reply-To: <seLyBDV5c8IqeRPkI3hyYz6kOmosatntZoM-RuezYj8=.2a90c730-3c9c-4efb-8318-0af2dd74e9a6@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Aid3vKSu2kPE3SGY2yvQntUi4cE8fOZmlJ5Y1bVz-Xs=.237ee245-302c-4426-b2b1-46ff7bbdcb46@github.com>
 <seLyBDV5c8IqeRPkI3hyYz6kOmosatntZoM-RuezYj8=.2a90c730-3c9c-4efb-8318-0af2dd74e9a6@github.com>
Message-ID: <Bmm9p86DOokTlma-jd4FR1RbSiCvI2S3Mpct_vEltaI=.d1bbd5e9-bfe3-4b4b-894f-50a19a8e9cde@github.com>

On Tue, 21 Feb 2023 23:10:44 GMT, SWinxy <duke at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add instanceof check
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 344:
> 
>> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
>> 343:         if (v != null && c instanceof AbstractButton
>> 344:                 && ((AbstractButton) c).getIcon() == null) {
> 
> We already know for certain that `c` is an AbstractButton. The first thing in the paint call, the component is casted. Why cast again when we can reuse the variable:
> Suggestion:
> 
>         if (v != null && b.getIcon() == null) {
> 
> 
> (also on ln 309 we could do the same thing)

Totally correct. Updated

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Wed Feb 22 00:02:10 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Feb 2023 00:02:10 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v4]
In-Reply-To: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
Message-ID: <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>

> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
> 
> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
> 
> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.

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

  Remove redundant check and reuse var.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12520/files
  - new: https://git.openjdk.org/jdk/pull/12520/files/e18a63ce..6e692450

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/12520


From honkar at openjdk.org  Wed Feb 22 00:15:32 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Feb 2023 00:15:32 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v3]
In-Reply-To: <seLyBDV5c8IqeRPkI3hyYz6kOmosatntZoM-RuezYj8=.2a90c730-3c9c-4efb-8318-0af2dd74e9a6@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <Aid3vKSu2kPE3SGY2yvQntUi4cE8fOZmlJ5Y1bVz-Xs=.237ee245-302c-4426-b2b1-46ff7bbdcb46@github.com>
 <seLyBDV5c8IqeRPkI3hyYz6kOmosatntZoM-RuezYj8=.2a90c730-3c9c-4efb-8318-0af2dd74e9a6@github.com>
Message-ID: <GbmPSv7Pe4NWViuz9nntTfkAWZGwq_5-O1apVx0daPI=.fed49820-b338-403d-819b-14e6cfaf07c3@github.com>

On Tue, 21 Feb 2023 23:10:44 GMT, SWinxy <duke at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add instanceof check
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 344:
> 
>> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
>> 343:         if (v != null && c instanceof AbstractButton
>> 344:                 && ((AbstractButton) c).getIcon() == null) {
> 
> We already know for certain that `c` is an AbstractButton. The first thing in the paint call, the component is casted. Why cast again when we can reuse the variable:
> Suggestion:
> 
>         if (v != null && b.getIcon() == null) {
> 
> 
> (also on ln 309 we could do the same thing)

@SWinxy Looks cleaner. Thanks for the suggestion.

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

PR: https://git.openjdk.org/jdk/pull/12520


From honkar at openjdk.org  Wed Feb 22 00:15:29 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 22 Feb 2023 00:15:29 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v4]
In-Reply-To: <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>
Message-ID: <vEvLmm6ww7Xqk4Bkq7ci7zf5QS-hUAmaAfiPn2plZ0Q=.40e5baf5-18b5-4909-a025-954255766131@github.com>

On Wed, 22 Feb 2023 00:02:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
>> 
>> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
>> 
>> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant check and reuse var.

Changes look good.

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

Marked as reviewed by honkar (Committer).

PR: https://git.openjdk.org/jdk/pull/12520


From duke at openjdk.org  Wed Feb 22 04:00:27 2023
From: duke at openjdk.org (SWinxy)
Date: Wed, 22 Feb 2023 04:00:27 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v4]
In-Reply-To: <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>
Message-ID: <x71oDgjgx7x-U43m0IBcNujfCQzSpTn9sgJfIDUAg1o=.15f2b4d2-2306-4123-8a3d-62359c5ccf19@github.com>

On Wed, 22 Feb 2023 00:02:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
>> 
>> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
>> 
>> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant check and reuse var.

Marked as reviewed by SWinxy at github.com (no known OpenJDK username).

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

PR: https://git.openjdk.org/jdk/pull/12520


From abhiscxk at openjdk.org  Wed Feb 22 05:32:06 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Feb 2023 05:32:06 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues
Message-ID: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>

JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 

Observation:
The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.

Solution:

Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 

Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.

Steps to verify:

JBS contains the steps to reproduce the scenario.

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

Commit messages:
 - JEditorPane HTML Demo fix

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

PR: https://git.openjdk.org/jdk/pull/12707


From abhiscxk at openjdk.org  Wed Feb 22 05:32:06 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Feb 2023 05:32:06 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues
In-Reply-To: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
Message-ID: <8l6tq-zeo-izLL1iE_3S9z_z_czEKZOQ8E0IgmyEMA8=.e3762a67-841c-40e2-bcc3-f31865625d21@github.com>

On Wed, 22 Feb 2023 05:24:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
> 
> Observation:
> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
> 
> Solution:
> 
> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
> 
> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
> 
> Steps to verify:
> 
> JBS contains the steps to reproduce the scenario.

@azuev-java Request you to please review this PR.

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

PR: https://git.openjdk.org/jdk/pull/12707


From psadhukhan at openjdk.org  Wed Feb 22 06:16:55 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Feb 2023 06:16:55 GMT
Subject: Integrated: 8041447: Test javax/swing/dnd/7171812/bug7171812.java
 fails with java.lang.RuntimeException: Test failed, scroll on drag doesn't work
In-Reply-To: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
References: <uOs8YGOmi-VhtYfqBhZ2sp63E6LC38r2SPo8OS_PBgM=.2567b104-b687-44d6-b3f0-69edbc9fefa3@github.com>
Message-ID: <vwUffaYT93tXpSgJghGFpuAKY8gU17HcrF7T4oBlRs8=.08698f6a-c72b-414c-ae58-f7ed52c96483@github.com>

On Thu, 12 Jan 2023 08:02:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test probably was failing few years back due to samevm mode.
> It's not failing now but made some robot safeguards.
> Several iterations are passing in all CI platforms. Link in JBS.

This pull request has now been integrated.

Changeset: 2c52cf07
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c52cf07469970f730aa7397f9f6b98534af3a44
Stats:     34 lines in 2 files changed: 20 ins; 4 del; 10 mod

8041447: Test javax/swing/dnd/7171812/bug7171812.java fails with java.lang.RuntimeException: Test failed, scroll on drag doesn't work

Reviewed-by: tr, serb

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

PR: https://git.openjdk.org/jdk/pull/11959


From jwaters at openjdk.org  Wed Feb 22 06:30:59 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 22 Feb 2023 06:30:59 GMT
Subject: Integrated: 8302838: jabswitch main() should avoid calling exit
 explicitly
In-Reply-To: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>
References: <GeONcAxlbrNA4YJNI76DC4PiQqDUfLpvWeVUgHCgeug=.5bb9f6d3-e15b-40fb-b90a-5ec62878ef13@github.com>
Message-ID: <AaqGVs2f_slH2cMtGQosPModgS4Vx_ey_0H2UufXGM4=.09660f77-8773-435c-9d49-a8c9d85b010d@github.com>

On Mon, 20 Feb 2023 08:10:54 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> In jabswitch, main is defined as `void main()`, which requires an explicit exit call whenever an error occurs, and extra error checking code on our part. Visual C++ will automatically convert all instances of `void main()` to return 0 in all cases anyway, and there isn't anything gained from using this custom signature when the same can be achieved by simply returning the error value normally, so I propose we simply change it to the regular `int main` signature

This pull request has now been integrated.

Changeset: cba817ae
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cba817ae590d1130196d7f9d6e75b8d9b37d384b
Stats:     6 lines in 1 file changed: 1 ins; 4 del; 1 mod

8302838: jabswitch main() should avoid calling exit explicitly

Reviewed-by: serb

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

PR: https://git.openjdk.org/jdk/pull/12650


From psadhukhan at openjdk.org  Wed Feb 22 06:38:45 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Feb 2023 06:38:45 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v4]
In-Reply-To: <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>
Message-ID: <5tHEJ_SaUaPVrOgK3gwrN3EI71pfqXvNX5T8XS2yJL8=.fb0a9adf-7b64-416a-87c5-35db98c2f771@github.com>

On Wed, 22 Feb 2023 00:02:10 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
>> 
>> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
>> 
>> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant check and reuse var.

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 343:

> 341:         final String text;
> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
> 343:         if (v != null && b.getIcon() == null) {

I think you can store `b.getIcon` same as `text` variable and reuse it down below too as it is now being called more than once

src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 344:

> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
> 343:         if (v != null && b.getIcon() == null) {
> 344:             // use zero insets for view when HTML contains an image

I guess it should be "**does not** contain an image", right?

test/jdk/javax/swing/JButton/HtmlButtonWithTextAndIcon.java line 27:

> 25: /* @test
> 26:  * @bug 8302173
> 27:  * @requires (os.family == "mac")

Is this required? HtmlButtonImageTest is being tested for all platforms even though fix was in mac so I think we should make this test also platform-agnostic..

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

PR: https://git.openjdk.org/jdk/pull/12520


From duke at openjdk.org  Wed Feb 22 07:48:48 2023
From: duke at openjdk.org (Tres Finocchiaro)
Date: Wed, 22 Feb 2023 07:48:48 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v4]
In-Reply-To: <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
Message-ID: <yUY1yZbhhoxINJZEqhDoIRvUebCWeMjtcef9lbFxONw=.d72428f7-db5b-481e-9dbc-58aefaa561e1@github.com>

On Tue, 29 Nov 2022 10:36:32 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
>> 
>> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
>> 
>> Four rectangles are printed:
>> 1. size 300x100, portrait orientation
>> 2. size 300x100, landscape orientation
>> 3. size 100x300, portrait orientation
>> 4. size 100x300, landscape orientation
>> 
>> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
>> 
>> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
>> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
>> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
>> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
>> 
>> The Cocoa code that shows NSPrintInfo behavior:
>> 
>> #import <Cocoa/Cocoa.h>
>> 
>> int main()
>> {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSApp = [NSApplication sharedApplication];
>> 
>>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>>     #define NS_PORTRAIT NSPaperOrientationPortrait
>>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>>     #else // code for SDK 10.8 or older
>>     #define NS_PORTRAIT NSPortraitOrientation
>>     #define NS_LANDSCAPE NSLandscapeOrientation
>>     #endif
>> 
>>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
>> 
>>     printf("create default print info\n");
>>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>>     NSSize size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("call setUpPrintOperationDefaultValues\n");
>>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     double w = 300.0;
>>     double h = 100.0;
>>     printf("set size: [%f, %f]\n", w, h);
>>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("Set NS_PORTRAIT orientation\n");
>>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     [NSApp run];
>> 
>>     [NSApp release];
>>     [pool release];
>>     return(EXIT_SUCCESS);
>> } 
>> 
>> 
>> On macOS Mojave 10.14.5 it prints:
>> 
>> 
>> NS_PORTRAIT: 0
>> NS_LANDSCAPE: 1
>> create default print info
>> orientation: 0, paper size: [612.000000, 792.000000]
>> call setUpPrintOperationDefaultValues
>> orientation: 0, paper size: [612.000000, 792.000000]
>> set size: [300.000000, 100.000000]
>> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
>> Set NS_PORTRAIT orientation
>> orientation: 0, paper size: [100.000000, 300.000000] // size flip
>> ``` 
>> 
>> There are four possible cases for printing a rectangle with different size and orientation:
>> 1. Input: paper size: (w > h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>>   Note: width and height are swapped
>> 2. Input: paper size: (w > h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
>> 3. Input: paper size: (w < h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
>> 4. Input: paper size: (w < h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>>   Note: width and height are swapped
>> 
>> Only for cases 1 and 4 the final width and height are swapped.
>> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
>> 
>> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
>> Setting requested size leads that subsequent orientation flips width and height.
>> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
>> 
>> Printed rectangles before and after the fix:
>> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
>> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
>> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
>> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
>> 
>> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in FlipPageFormat class comments

Bumping for bots

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

PR: https://git.openjdk.org/jdk/pull/10808


From asemenov at openjdk.org  Wed Feb 22 09:53:42 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 22 Feb 2023 09:53:42 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4]
In-Reply-To: <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
Message-ID: <_XdoQtLnEy2O76QBmBrcbpLztbl1vV-bFMcTfj1cMLo=.c9124253-40cd-4399-b416-e070186ffc69@github.com>

On Wed, 9 Nov 2022 09:42:00 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
>> 
>> @forantar @azuev-java @mrserb please review.
>> 
>> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We are not using author tags in tests either - but that's just a nitpick.

Some comment so that the pull request is not closed.

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

PR: https://git.openjdk.org/jdk/pull/8578


From pminborg at openjdk.org  Wed Feb 22 11:48:56 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 22 Feb 2023 11:48:56 GMT
Subject: Integrated: 8302849: SurfaceManager might expose partially constructed
 object
In-Reply-To: <Ppas5MKQoxJHK8icV5-hsTlihbeF-47uwx2mrtIwB-g=.196f6cc9-4b0e-49a4-9e36-f629d47f0175@github.com>
References: <Ppas5MKQoxJHK8icV5-hsTlihbeF-47uwx2mrtIwB-g=.196f6cc9-4b0e-49a4-9e36-f629d47f0175@github.com>
Message-ID: <VnJSyqyw76KueGp8U5cBmSCzjk3dyJVHfVL6_KKExGw=.2c9e139c-8cb3-43f9-9530-b2836d27b0b3@github.com>

On Mon, 20 Feb 2023 10:25:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add `volatile` to a variable declaration in order to prevent partially initialized objects to be observed by threads.
> 
> `SurfaceManager` is using a lazily initialized cacheMap that is initialized using a double-checked locking mechanism. Generally, objects initialized using such constructs need to be declared volatile. 
> 
> See https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java

This pull request has now been integrated.

Changeset: 63ef2143
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63ef2143289f4aac52c8b2a6b555ed2b33dc1c07
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8302849: SurfaceManager might expose partially constructed object

Reviewed-by: serb

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

PR: https://git.openjdk.org/jdk/pull/12654


From duke at openjdk.org  Wed Feb 22 17:14:46 2023
From: duke at openjdk.org (SWinxy)
Date: Wed, 22 Feb 2023 17:14:46 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <oH9qg_uC5dti6S14OdBk7V8_eQQN7jtSuv7L-Ph_-AA=.32c6cd35-72a8-42a7-9af6-f702e1090ef7@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
 <Pdw49xZQ0YKrcoEKDJOu_J-Gj5bB7r3T5mE8F84rpJw=.21d4c3f4-6a0f-4531-8ddf-b27623f14f68@github.com>
 <oH9qg_uC5dti6S14OdBk7V8_eQQN7jtSuv7L-Ph_-AA=.32c6cd35-72a8-42a7-9af6-f702e1090ef7@github.com>
Message-ID: <mDQqZZVam7td7q2V3oVbmbjSd6fKkAWiC3inX2rFHO0=.6526697d-6c02-4030-9df2-b21e67bbef8d@github.com>

On Fri, 9 Dec 2022 00:38:47 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Looks like there are issues with my PR that I haven't noticed. Shoot.
>
>> Looks like there are issues with my PR that I haven't noticed. Shoot.
> 
> While you are working on it you can move the PR to the draft state.

@mrserb would you kindly give feedback? (Linux builds failing because they feel like it.)

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

PR: https://git.openjdk.org/jdk/pull/10416


From dnguyen at openjdk.org  Wed Feb 22 17:52:01 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Feb 2023 17:52:01 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v5]
In-Reply-To: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
Message-ID: <M5hsTH0KhbsbuzQHseMgwm0wDeO2vazfjgcUz6hcM4w=.07f3d990-7e6f-42a6-94e8-e21aca37735c@github.com>

> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
> 
> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
> 
> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.

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

  Add reusable icon var. Update comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12520/files
  - new: https://git.openjdk.org/jdk/pull/12520/files/6e692450..e8a06771

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12520&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/12520


From dnguyen at openjdk.org  Wed Feb 22 17:53:21 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 22 Feb 2023 17:53:21 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v4]
In-Reply-To: <5tHEJ_SaUaPVrOgK3gwrN3EI71pfqXvNX5T8XS2yJL8=.fb0a9adf-7b64-416a-87c5-35db98c2f771@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <j-GrGXW2GlZTDPg7QtssYMQIYW5KEejlUzOvs10DR4A=.7debd2fe-6f64-4a5d-b348-d3335f2c6897@github.com>
 <5tHEJ_SaUaPVrOgK3gwrN3EI71pfqXvNX5T8XS2yJL8=.fb0a9adf-7b64-416a-87c5-35db98c2f771@github.com>
Message-ID: <FGs_l2WOimFPMUHZ5NQHbNzsoJtTDP-z3wkCBywVo8U=.ffe1a555-0408-4923-90c9-110fc09a3e90@github.com>

On Wed, 22 Feb 2023 06:25:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant check and reuse var.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 343:
> 
>> 341:         final String text;
>> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
>> 343:         if (v != null && b.getIcon() == null) {
> 
> I think you can store `b.getIcon` same as `text` variable and reuse it down below too as it is now being called more than once

Good idea. Added

> src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java line 344:
> 
>> 342:         final View v = (View)c.getClientProperty(BasicHTML.propertyKey);
>> 343:         if (v != null && b.getIcon() == null) {
>> 344:             // use zero insets for view when HTML contains an image
> 
> I guess it should be "**does not** contain an image", right?

This comment is confusing now that it deals with button icon images and HTML images. I updated the comment

> test/jdk/javax/swing/JButton/HtmlButtonWithTextAndIcon.java line 27:
> 
>> 25: /* @test
>> 26:  * @bug 8302173
>> 27:  * @requires (os.family == "mac")
> 
> Is this required? HtmlButtonImageTest is being tested for all platforms even though fix was in mac so I think we should make this test also platform-agnostic..

I would but different L&F's show HTML content differently. For example, here's Metal:
![failImage](https://user-images.githubusercontent.com/96267980/220711014-a9b6be59-9a53-4044-9763-fffe157c5d73.png)

Other L&F's are slightly different as well, and this would require the test to handle each L&F differently. The changes were only for Aqua L&F, and the original issue fix was also for only Aqua L&F. The original issue was that the HTML image (not icon) would appear outside the bounds of the button, similar to the icon here.

So, I made this test only for macOS && Aqua L&F.

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

PR: https://git.openjdk.org/jdk/pull/12520


From serb at openjdk.org  Wed Feb 22 19:35:42 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 22 Feb 2023 19:35:42 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals()
In-Reply-To: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
Message-ID: <-z17sV_KcX4rTZcqwofHE4x7LmT-1-dmqgoESMZpNl8=.8692ec3e-9a75-4577-a2d1-6bb60d62600e@github.com>

On Sun, 25 Sep 2022 04:01:26 GMT, SWinxy <duke at openjdk.org> wrote:

> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

You can restart the presubmit tests by merging from master to make it green.

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

PR: https://git.openjdk.org/jdk/pull/10416


From xuelei at openjdk.org  Wed Feb 22 19:41:29 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 22 Feb 2023 19:41:29 GMT
Subject: RFR: 8302495: update for deprecated sprintf for java.desktop [v2]
In-Reply-To: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
References: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
Message-ID: <QvMra0UZgHLe8AtqXmQq05Bp-U8gs3ZVmRXatUoj_0A=.6d09bfd4-73a6-4a7d-953e-0924b0698a82@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14 because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in java.desktop components.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  revert freetype update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12565/files
  - new: https://git.openjdk.org/jdk/pull/12565/files/9c290eec..ec06ba9a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12565&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12565&range=00-01

  Stats: 16 lines in 2 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/12565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12565/head:pull/12565

PR: https://git.openjdk.org/jdk/pull/12565


From xuelei at openjdk.org  Wed Feb 22 19:44:37 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 22 Feb 2023 19:44:37 GMT
Subject: RFR: 8302495: update for deprecated sprintf for java.desktop
In-Reply-To: <MGbT7kXybrpTCiM4cFtciem4W6zPHumw0V8G4B9nsPM=.be07ee3b-5582-432b-afd4-627fda3480ea@github.com>
References: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
 <MGbT7kXybrpTCiM4cFtciem4W6zPHumw0V8G4B9nsPM=.be07ee3b-5582-432b-afd4-627fda3480ea@github.com>
Message-ID: <OLGmS8aYffBUxJiCTzPUI_1P3Xk3_QYMyOk9WbXs-ZE=.aa49860b-0583-4f78-a50c-ef16a5780775@github.com>

On Thu, 16 Feb 2023 21:46:19 GMT, Phil Race <prr at openjdk.org> wrote:

> This is a fairly extensive set of changes so I'll contact you off-line to make sure you have done adequate testing.

Thank you for your looking into the issue.

I'm new to java.desktop.  Exception the regression tests, what else should I run to make sure everything is OK?  Can someone in Oracle help me run Mach5 jobs for tier1, tier2 and jdk_desktop?

> Also the changes in freetype must be reverted. This is a 3rd party library.

The update in freetype was reverted.

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

PR: https://git.openjdk.org/jdk/pull/12565


From kizune at openjdk.org  Wed Feb 22 20:01:17 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 22 Feb 2023 20:01:17 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues
In-Reply-To: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
Message-ID: <9xMZAsdWlK3jj0DB2oXnYXe5geCc7Eg-j_uiQFrw4Do=.0a81ff71-3195-4593-8675-d4c820e7ddd2@github.com>

On Wed, 22 Feb 2023 05:24:20 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
> 
> Observation:
> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
> 
> Solution:
> 
> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
> 
> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
> 
> Steps to verify:
> 
> JBS contains the steps to reproduce the scenario.

You might to bump up the copyright year in both headers. Other than that looks good.

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

PR: https://git.openjdk.org/jdk/pull/12707


From duke at openjdk.org  Wed Feb 22 20:49:43 2023
From: duke at openjdk.org (SWinxy)
Date: Wed, 22 Feb 2023 20:49:43 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals() [v2]
In-Reply-To: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
Message-ID: <KrvF1dlhmqqpHYs3FoM75JMaShiDVQ7V--Mn4MneDzc=.d11d49ba-6c63-4a83-a9c7-f4adcc613cca@github.com>

> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

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

 - Merge branch 'master' into font_equals
 - Removal of AttributeValues.equals(Object, Object) did not replace with Object.equals
 - Reinstate public API methods
   
   Whoops
 - Forgor to update copyright year
 - Other font classes where equals(Object) can be improved
 - Revert variable name changes back to their original (instead of o1), suggested by ExE-Boss
 - Some font classes rely on blind casting to implement Object.equals()
   
   Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10416/files
  - new: https://git.openjdk.org/jdk/pull/10416/files/080a4b16..c3e564ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10416&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10416&range=00-01

  Stats: 550789 lines in 8696 files changed: 271826 ins; 172577 del; 106386 mod
  Patch: https://git.openjdk.org/jdk/pull/10416.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10416/head:pull/10416

PR: https://git.openjdk.org/jdk/pull/10416


From prr at openjdk.org  Thu Feb 23 00:11:33 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Feb 2023 00:11:33 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals() [v2]
In-Reply-To: <KrvF1dlhmqqpHYs3FoM75JMaShiDVQ7V--Mn4MneDzc=.d11d49ba-6c63-4a83-a9c7-f4adcc613cca@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
 <KrvF1dlhmqqpHYs3FoM75JMaShiDVQ7V--Mn4MneDzc=.d11d49ba-6c63-4a83-a9c7-f4adcc613cca@github.com>
Message-ID: <Sn0HDxkb89rkqnTmHme_uQMWKHrIwke-CQkfhpHqG9I=.d2823ca0-e3d8-4fbc-82fd-bf4efb978c20@github.com>

On Wed, 22 Feb 2023 20:49:43 GMT, SWinxy <duke at openjdk.org> wrote:

>> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.
>
> SWinxy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into font_equals
>  - Removal of AttributeValues.equals(Object, Object) did not replace with Object.equals
>  - Reinstate public API methods
>    
>    Whoops
>  - Forgor to update copyright year
>  - Other font classes where equals(Object) can be improved
>  - Revert variable name changes back to their original (instead of o1), suggested by ExE-Boss
>  - Some font classes rely on blind casting to implement Object.equals()
>    
>    Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

Whoa ! This is a lot of changes for what benefit ? 
To introduce changes in behaviour in code that has been stable for 20 years ?
Every single one of these changes will need very careful analysis and testing.
Frankly, I'm not very interested in taking changes like this.

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

PR: https://git.openjdk.org/jdk/pull/10416


From abhiscxk at openjdk.org  Thu Feb 23 03:22:19 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Feb 2023 03:22:19 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v2]
In-Reply-To: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
Message-ID: <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>

> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
> 
> Observation:
> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
> 
> Solution:
> 
> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
> 
> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
> 
> Steps to verify:
> 
> JBS contains the steps to reproduce the scenario.

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

  Copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12707/files
  - new: https://git.openjdk.org/jdk/pull/12707/files/2cc92c75..1bf80092

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12707&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12707&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12707


From abhiscxk at openjdk.org  Thu Feb 23 03:22:19 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Feb 2023 03:22:19 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues
In-Reply-To: <9xMZAsdWlK3jj0DB2oXnYXe5geCc7Eg-j_uiQFrw4Do=.0a81ff71-3195-4593-8675-d4c820e7ddd2@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
 <9xMZAsdWlK3jj0DB2oXnYXe5geCc7Eg-j_uiQFrw4Do=.0a81ff71-3195-4593-8675-d4c820e7ddd2@github.com>
Message-ID: <3Dphs8Lh7B2mKCoLMZfVFEPAQq_QqF1hGlkpNI4KpSc=.6146cff9-9b99-455d-ad32-7c101437cd88@github.com>

On Wed, 22 Feb 2023 19:58:08 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

> You might to bump up the copyright year in both headers. Other than that looks good.

Copyright year updated.

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

PR: https://git.openjdk.org/jdk/pull/12707


From psadhukhan at openjdk.org  Thu Feb 23 03:25:05 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 23 Feb 2023 03:25:05 GMT
Subject: RFR: 8302173: Button border overlaps with button icon on macOS
 system LaF [v5]
In-Reply-To: <M5hsTH0KhbsbuzQHseMgwm0wDeO2vazfjgcUz6hcM4w=.07f3d990-7e6f-42a6-94e8-e21aca37735c@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
 <M5hsTH0KhbsbuzQHseMgwm0wDeO2vazfjgcUz6hcM4w=.07f3d990-7e6f-42a6-94e8-e21aca37735c@github.com>
Message-ID: <tuTG4zg7ZpNZU5akeLbPY09DuqAo3DMEPwF7F-RiKS4=.1a1950e2-5808-49af-a79a-ea0348bec5b7@github.com>

On Wed, 22 Feb 2023 17:52:01 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
>> 
>> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
>> 
>> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add reusable icon var. Update comment.

ok looks fine

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

Marked as reviewed by psadhukhan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12520


From kizune at openjdk.org  Thu Feb 23 17:02:36 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 23 Feb 2023 17:02:36 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v2]
In-Reply-To: <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
 <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
Message-ID: <aejvaCrkBkptUKpvOlK6p_6EODxTbwyedkHfX4jHDEg=.d850c79e-1580-461f-b55a-19d4dd542e24@github.com>

On Thu, 23 Feb 2023 03:22:19 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
>> 
>> Observation:
>> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
>> 
>> Solution:
>> 
>> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
>> 
>> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
>> 
>> Steps to verify:
>> 
>> JBS contains the steps to reproduce the scenario.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

Marked as reviewed by kizune (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12707


From duke at openjdk.org  Thu Feb 23 17:55:59 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 23 Feb 2023 17:55:59 GMT
Subject: RFR: 8298385: Some font classes rely on blind casting to implement
 Object.equals() [v2]
In-Reply-To: <KrvF1dlhmqqpHYs3FoM75JMaShiDVQ7V--Mn4MneDzc=.d11d49ba-6c63-4a83-a9c7-f4adcc613cca@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
 <KrvF1dlhmqqpHYs3FoM75JMaShiDVQ7V--Mn4MneDzc=.d11d49ba-6c63-4a83-a9c7-f4adcc613cca@github.com>
Message-ID: <gAtSS5h0A0HloeQ5ivpfJzOnIg2OHEz1MQV4SLu61gc=.0833244f-d3ea-4912-b490-009ad9cbf10d@github.com>

On Wed, 22 Feb 2023 20:49:43 GMT, SWinxy <duke at openjdk.org> wrote:

>> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.
>
> SWinxy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into font_equals
>  - Removal of AttributeValues.equals(Object, Object) did not replace with Object.equals
>  - Reinstate public API methods
>    
>    Whoops
>  - Forgor to update copyright year
>  - Other font classes where equals(Object) can be improved
>  - Revert variable name changes back to their original (instead of o1), suggested by ExE-Boss
>  - Some font classes rely on blind casting to implement Object.equals()
>    
>    Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

Gah. Alright.

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

PR: https://git.openjdk.org/jdk/pull/10416


From duke at openjdk.org  Thu Feb 23 17:56:00 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 23 Feb 2023 17:56:00 GMT
Subject: Withdrawn: 8298385: Some font classes rely on blind casting to
 implement Object.equals()
In-Reply-To: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
References: <MNh-Tkp9yjvjEf2IonF4d-x-HGbo6LLEkaPeJ2MO708=.6bd99846-c2ff-4eae-b8b0-2cb9c679f2f9@github.com>
Message-ID: <mZU36x67CwHSkj83Z91wrLrhavjoFRQ6SUtK-puhIY0=.13338315-2c62-41e7-98b4-7a8cd779a879@github.com>

On Sun, 25 Sep 2022 04:01:26 GMT, SWinxy <duke at openjdk.org> wrote:

> Some also had two separate methods to check equality, one calling the other. Objects.equals() is used in some places as a replacement for a local copy of the function. In the end, the equals methods become quicker to understand their checks, more condensed, and becomes more in line with other equality methods in the JDK.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/10416


From duke at openjdk.org  Thu Feb 23 18:45:15 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 23 Feb 2023 18:45:15 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v13]
In-Reply-To: <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
Message-ID: <ox_82tCxyvEU0WE1ytVbaTlYKvO_TVLJmo1OWxIx500=.05d3702a-0343-47ab-8507-aae483ef1e7d@github.com>

On Sun, 5 Feb 2023 09:55:27 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.

I don't know if I like the use of Maps. I think I would prefer doing it via an enhanced switch. I've written a sketch of what I would write. Untested and probably *very* wrong, but I like it.


static Color hexToColor(String digits) {
    if (digits.startsWith("#")) {
        digits = digits.substring(1);
    }

    try {
        int a = Integer.parseInt(digits, 16);

        return switch (digits.length()) {
            case 3 -> new Color((a & 0xF00) << 24 | (a & 0xF0) << 16 | (a & 0xF) << 8 | 0xFF);
            case 4 -> new Color((a & 0xF000) << 24 | (a & 0xF00) << 16 | (a & 0xF0) << 8 | (a & 0xF));
            case 6 -> new Color((a & 0xFF0000) << 24 | (a & 0xFF00) << 16 | (a & 0xFF) << 8 | 0xFF);
            case 8 -> new Color(a);
            default -> null;
        }
    } catch (NumberFormatException e) {
        return null;
    }
}


I don't like when PRs languish. It sucks.

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

PR: https://git.openjdk.org/jdk/pull/10317


From aivanov at openjdk.org  Thu Feb 23 20:16:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Feb 2023 20:16:39 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <Qekkj0igM94vCQHF9RTZRrrDmqBbPGVBN2o3wtUhpIw=.77da8875-992e-4872-9cdf-8bb3b92438cd@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>
 <Mt6Vv2YjMnw1SSrvWkX06N91CWwKnlJu_cPtxhXD7KY=.891d231c-5081-4f4c-88cc-53cbde4df3b5@github.com>
 <Qekkj0igM94vCQHF9RTZRrrDmqBbPGVBN2o3wtUhpIw=.77da8875-992e-4872-9cdf-8bb3b92438cd@github.com>
Message-ID: <cSyFymNMn888AAQLMbfKb4U4APfb2PaiTv2_bUPtS_8=.bf768e0b-57f9-4d93-b696-b48069a3f9c4@github.com>

On Fri, 17 Feb 2023 00:26:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> For this reason, GC logs are enabled. If, for whatever reason, the call to `System.gc()` is ignored, we'll see it in the test log. Then a specific GC could be selected, for example, or another fix implemented.
>> 
>> OOME does not guarantee a full GC cycle either.
>> 
>> Having the above in mind, I'd rather keep it simple.
>
>>For this reason, GC logs are enabled. If, for whatever reason, the call to System.gc() is ignored, we'll see it in the test log. Then a specific GC could be selected, for example, or another fix implemented.
> 
> As of now this test can be executed with different GC, and some of them can skip System.gc().
> 
>>OOME does not guarantee a full GC cycle either.
> 
> But it guarantee that at least some GC will be always run, unlike System.gc().

I followed the piece of advice in the [JBS comment](https://bugs.openjdk.org/browse/JDK-8300727?focusedCommentId=14560139&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14560139).

If using `System.gc()` is good enough for testing references:

https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60

https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92

Then it should be good enough for this test too.

Perhaps, the same effect could be achieved by causing OOME in a loop. However, using `System.gc()` makes the intention clearer: *run GC*, wait for the phantom reference to be cleared and enqueued.

I can explicitly select a GC: `-XX:+UseG1GC` (default) or `-XX:+UseSerialGC`.

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

PR: https://git.openjdk.org/jdk/pull/12594


From dnguyen at openjdk.org  Thu Feb 23 20:44:19 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 23 Feb 2023 20:44:19 GMT
Subject: Integrated: 8302173: Button border overlaps with button icon on macOS
 system LaF
In-Reply-To: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
References: <A64exX5ljHBiTFqPqQ3LPZUK9P73MMN7MVflRODWpLE=.89d10c66-3eb7-4800-bf87-eafe8954b595@github.com>
Message-ID: <LbN66pYVk1uUucer55xd-E0kGYZYOaCKvMXBL4ASovI=.1ed5336d-c85c-4096-b221-00f0caa44787@github.com>

On Sat, 11 Feb 2023 00:23:05 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Previous fix to HTML in AquaButtonUI fixed spacing issue for HTML images in a JButton in Aqua L&F. The new issue comes from having text inside the HTML as the button's text. If an icon is used, this icon exceeds the bounds of the button and overlaps the border.
> 
> Added additional logic to check if HTML contains an img. If so, apply the previous fix. Otherwise, the original implementation for Aqua's JButton HTML layout works correctly, so use this behavior.
> 
> Added a test based on the provided test in the bug report. Automated the test using a BufferedImage and changed the icon color to RED. Tested with multiple runs on Aqua L&F, and the test passes with the update where it fails without the update.

This pull request has now been integrated.

Changeset: 1a078714
Author:    Damon Nguyen <dnguyen at openjdk.org>
Committer: Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1a078714546c7582c310537dcae91b521f3c2b40
Stats:     177 lines in 2 files changed: 163 ins; 3 del; 11 mod

8302173: Button border overlaps with button icon on macOS system LaF

Reviewed-by: honkar, psadhukhan

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

PR: https://git.openjdk.org/jdk/pull/12520


From prr at openjdk.org  Thu Feb 23 22:24:05 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Feb 2023 22:24:05 GMT
Subject: RFR: 8302813: awt.image.incrementaldraw can use
 Boolean.parseBoolean() to parse the system property
In-Reply-To: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
References: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
Message-ID: <sCTjCplB19_cz2WNWGwTsmtVuDBzITpPU1gITAagyNQ=.9122a286-975f-4e5c-87b7-400dfea8a6ad@github.com>

On Sat, 18 Feb 2023 22:18:52 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.
> 
> Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

This change is both un-needed and wrong.

The property is not normally set so GetPropertyAction returns null
Boolean.parseBoolean(null) will return Boolean.FALSE
However the existing code treats null (unspecified) the same as TRUE

So your proposed change breaks apps for no value.

How did you test it ? I see no test here, nor indication that you ran it.

This speaks to how these "harmless" changes can be anything but,
and it takes time and effort to review them for no value to our end-users.

BTW its bizarre to suggest updating this one but not incRate.

However I see no need for this change at all.

So please stop proposing changes that add no value to users and maybe
instead focus on some small test and functional fixes.

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

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12639


From duke at openjdk.org  Thu Feb 23 22:29:15 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 23 Feb 2023 22:29:15 GMT
Subject: RFR: 8302813: awt.image.incrementaldraw can use
 Boolean.parseBoolean() to parse the system property
In-Reply-To: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
References: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
Message-ID: <jBmrIkGJLars9Js-u9967_xoHqVyJJ6_vkd9EaH4z2E=.b8373098-f399-4a3f-94da-e9e9bbe6cbcf@github.com>

On Sat, 18 Feb 2023 22:18:52 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.
> 
> Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

Oh. Sorry :(

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

PR: https://git.openjdk.org/jdk/pull/12639


From duke at openjdk.org  Thu Feb 23 22:29:16 2023
From: duke at openjdk.org (SWinxy)
Date: Thu, 23 Feb 2023 22:29:16 GMT
Subject: Withdrawn: 8302813: awt.image.incrementaldraw can use
 Boolean.parseBoolean() to parse the system property
In-Reply-To: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
References: <0mHk6u6LUnXAxqrDC8U4-qGYimD4_yH6XEwNCF8eVQ8=.5581ffa5-5c56-408f-9bce-789f8f26f2e4@github.com>
Message-ID: <79Chu5c3M3N2GE-MF81HZCZQEjRGYNiS0565ZxYsZfs=.530cb342-272f-4b76-89c7-a7235f12c6c1@github.com>

On Sat, 18 Feb 2023 22:18:52 GMT, SWinxy <duke at openjdk.org> wrote:

> Please review this change which moves the parsing of the `awt.image.incrementaldraw` property from the static initializer block into the field itself by invoking `Boolean.parseBoolean()` on the system property getter.
> 
> Hopefully in the near future we can do away with `AccessController`s and simply go with `System.getProperty` :)

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/12639


From prr at openjdk.org  Thu Feb 23 23:15:05 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Feb 2023 23:15:05 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <cSyFymNMn888AAQLMbfKb4U4APfb2PaiTv2_bUPtS_8=.bf768e0b-57f9-4d93-b696-b48069a3f9c4@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>
 <Mt6Vv2YjMnw1SSrvWkX06N91CWwKnlJu_cPtxhXD7KY=.891d231c-5081-4f4c-88cc-53cbde4df3b5@github.com>
 <Qekkj0igM94vCQHF9RTZRrrDmqBbPGVBN2o3wtUhpIw=.77da8875-992e-4872-9cdf-8bb3b92438cd@github.com>
 <cSyFymNMn888AAQLMbfKb4U4APfb2PaiTv2_bUPtS_8=.bf768e0b-57f9-4d93-b696-b48069a3f9c4@github.com>
Message-ID: <QKEcXxWR4Dd6FGqr2Jiqcfiv9t5GhwO9Pka5x90WCgI=.c1e150d6-68f3-48ab-986e-d90b909ccb24@github.com>

On Thu, 23 Feb 2023 20:14:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>>For this reason, GC logs are enabled. If, for whatever reason, the call to System.gc() is ignored, we'll see it in the test log. Then a specific GC could be selected, for example, or another fix implemented.
>> 
>> As of now this test can be executed with different GC, and some of them can skip System.gc().
>> 
>>>OOME does not guarantee a full GC cycle either.
>> 
>> But it guarantee that at least some GC will be always run, unlike System.gc().
>
> I followed the piece of advice in the [JBS comment](https://bugs.openjdk.org/browse/JDK-8300727?focusedCommentId=14560139&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14560139).
> 
> If using `System.gc()` is good enough for testing references:
> 
> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60
> 
> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92
> 
> Then it should be good enough for this test too.
> 
> Perhaps, the same effect could be achieved by causing OOME in a loop. However, using `System.gc()` makes the intention clearer: *run GC*, wait for the phantom reference to be cleared and enqueued.
> 
> I can explicitly select a GC: `-XX:+UseG1GC` (default) or `-XX:+UseSerialGC`.

There are lots of tests that rely on System.gc() actually triggering a gc.
SFAIK all collectors we have today will obey it unless you use
-XX:+DisableExplicitGC
If you can make the test work with that then that would be interesting but calling just System.gc() is no worse than all those other tests.

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

PR: https://git.openjdk.org/jdk/pull/12594


From prr at openjdk.org  Thu Feb 23 23:36:08 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Feb 2023 23:36:08 GMT
Subject: RFR: 8301254: UNIX sun/font coding does not detect SuSE in
 openSUSE Leap distribution [v3]
In-Reply-To: <-tpYJcPxbkQ6zMPv51AJR3aJFo809DTtMynt3qAvdgQ=.5e8f5be3-33f7-4663-87b6-66cf78e726ca@github.com>
References: <mT0PlFG6VxvcXjvjQjrvJLQqsHHLhB2aM74PzA_vDo8=.2759eb4a-97f7-4c9d-8806-08791f824c6c@github.com>
 <-tpYJcPxbkQ6zMPv51AJR3aJFo809DTtMynt3qAvdgQ=.5e8f5be3-33f7-4663-87b6-66cf78e726ca@github.com>
Message-ID: <3mUgrNVG7VbcNoknZrhF04MCHXGtRI3A9PEvJvhOrRI=.920b4dcd-12b9-4b90-87b7-a2e9ae978ad0@github.com>

On Tue, 7 Feb 2023 17:20:19 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> [JDK-8278549](https://bugs.openjdk.org/browse/JDK-8278549)` UNIX sun/font coding misses SUSE distro detection on recent distro SUSE 15` adds SuSE detection by checking SLES os name property in `/etc/os-release` file.
>> 
>> `opensuse/leap:15.4` docker defines os name property as `"openSUSE Leap"` in `/etc/os-release` file which is not recognized as SuSE.
>> 
>> The issue is reproduced with Oracle jdk-19.0.2 with custom fontconfig.SuSE.properties file copied to jdk-19.0.2/lib directory.
>> 
>> The fix checks if os name property from  `/etc/os-release` contains `SUSE`  substring.
>> 
>> Steps to reproduce.
>> - Download Oracle jdk-19.0.2
>> - Copy custom [fontconfig.SuSE.properties](https://bugs.openjdk.org/secure/attachment/102435/fontconfig.SuSE.properties) file to jdk-19.0.2/lib directory.
>> - Run the `opensuse/leap:15.4` docker and install freetype and dejavu fonts (do not install fontconfig)
>> 
>> docker run --rm --security-opt seccomp=unconfined -it opensuse/leap:15.4 bash
>> zypper install -y dejavu-fonts
>> zypper install -y freetype2
>> 
>> - Run HelloImage java sample in the docker
>> 
>> import javax.imageio.ImageIO;
>> import java.awt.*;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> 
>> public class HelloImage {
>> 
>>     public static void main(String[] args) throws Exception {
>> 
>>         BufferedImage buff = new BufferedImage(300, 200, BufferedImage.TYPE_INT_RGB);
>>         Graphics2D g = buff.createGraphics();
>>         g.setColor(Color.WHITE);
>>         g.fillRect(0, 0, buff.getWidth(), buff.getHeight());
>> 
>>         g.setColor(Color.BLUE);
>>         g.setFont(g.getFont().deriveFont(32f));
>>         g.drawString("Hello, Image!", 50, 50);
>>         g.dispose();
>> 
>>         File file = new File("hello-image.png");
>>         ImageIO.write(buff, "png", file);
>>     }
>> }
>> 
>> 
>> 
>> ./jdk-19.0.2/bin/javac HelloImage.java
>> ./jdk-19.0.2/bin/java HelloImage
>> Exception in thread "main" java.lang.NullPointerException: Cannot load from short array because "sun.awt.FontConfiguration.head" is null
>> 	at java.desktop/sun.awt.FontConfiguration.getVersion(FontConfiguration.java:1261)
>> 	at java.desktop/sun.awt.FontConfiguration.readFontConfigFile(FontConfiguration.java:221)
>> 	at java.desktop/sun.awt.FontConfiguration.init(FontConfiguration.java:105)
>> 	at java.desktop/sun.awt.X11FontManager.createFontConfiguration(X11FontManager.java:706)
>> 	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:352)
>> 	at java.desktop/sun.font.SunFontManager$2.run(SunFontManager.java:309)
>> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:318)
>> 	at java.desktop/sun.font.SunFontManager.<init>(SunFontManager.java:309)
>> 	at java.desktop/sun.awt.FcFontManager.<init>(FcFontManager.java:35)
>> 	at java.desktop/sun.awt.X11FontManager.<init>(X11FontManager.java:56)
>> 	at java.desktop/sun.font.PlatformFontInfo.createFontManager(PlatformFontInfo.java:37)
>> 	at java.desktop/sun.font.FontManagerFactory.getInstance(FontManagerFactory.java:51)
>> 	at java.desktop/java.awt.Font.getFont2D(Font.java:526)
>> 	at java.desktop/java.awt.Font$FontAccessImpl.getFont2D(Font.java:265)
>> 	at java.desktop/sun.font.FontUtilities.getFont2D(FontUtilities.java:151)
>> 	at java.desktop/sun.java2d.SunGraphics2D.checkFontInfo(SunGraphics2D.java:671)
>> 	at java.desktop/sun.java2d.SunGraphics2D.getFontInfo(SunGraphics2D.java:837)
>> 	at java.desktop/sun.java2d.pipe.GlyphListPipe.drawString(GlyphListPipe.java:46)
>> 	at java.desktop/sun.java2d.SunGraphics2D.drawString(SunGraphics2D.java:2931)
>> 	at HelloImage.main(HelloImage.java:17)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extract os name as ID from /etc/os-release file for fonts configuration

Marked as reviewed by prr (Reviewer).

If I read the code right, what you have now is good enough.

If the code really is duplicated 100% - just with different orders - then unifying seems like a good thing.
Up to you if you do it.
For the ordering I would need to research to be sure, but  I'd be inclined towards the order in MFontConfiguration
unless research shows that the names like fedora-release are going out of fashion and everyone is using lsb-release these days.
If they are then I'd move that to the front .. 

More logging is also fine.

A mapping file is something I'd leave until there's a demonstrated need for more than the suse family

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

PR: https://git.openjdk.org/jdk/pull/12260


From prr at openjdk.org  Thu Feb 23 23:49:07 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 23 Feb 2023 23:49:07 GMT
Subject: RFR: 8299333: Unify exceptions used by all variants of
 ICC_Profile.getInstance(null) [v2]
In-Reply-To: <n1X_Q5o8h9ZPLX9GJXNA-S8RlaHYihgoljl3ybocxCE=.5837e7aa-cf06-4f88-9c06-30971035a564@github.com>
References: <vcJUwGyej8Uk8AQC25VHJib-Tn0MMDATnf8H3JEZygQ=.8212bab6-583d-4e8b-9dce-15a94ef52c39@github.com>
 <n1X_Q5o8h9ZPLX9GJXNA-S8RlaHYihgoljl3ybocxCE=.5837e7aa-cf06-4f88-9c06-30971035a564@github.com>
Message-ID: <c1NTxXOmD40aWToTZ6YSJKQK2uQkm_hq7S4otTX7S1I=.ca969158-a7dc-44e0-a861-2f6920f646d2@github.com>

On Fri, 20 Jan 2023 20:20:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I tried to clean up the documentation in the `java.awt.color` package and specify how the `null` parameters are handled here and there. But it looks like the `ICC_profile` class is too specific so I would like to discuss it separately.
>> 
>> The ICC_Profile has these methods:
>>  * `getInstance(int)`      - always throws specified `IllegalArgumentException` on the wrong constant
>>  * `getInstance(byte[])` - always throws specified `IllegalArgumentException` on `null`
>>  * `getInstance(String fileName)` - always throws unspecified `NullPointerException` on `null`
>>  * `getInstance(InputStream)`      - thrown unspecified `NullPointerException` before [JDK-8227816](https://github.com/openjdk/jdk/commit/af20c6b9c4a3a21c1e2c7f56721e1077e7d8f388) and now throws specified but misleading `IOException: Stream closed` exception on `null`
>> 
>> So we have 3 methods that can get null as a parameter and each throw a different exception.
>> 
>> Note that all of the specs for the methods above have this part:
>> 
>>> @throws IllegalArgumentException If the stream does not contain valid ICC Profile data
>> 
>> So I have an idea to change `getInstance(String)` and `getInstance(InputStream)` to throw `IllegalArgumentException`  even if I personally prefer NPE to be thrown.
>> 
>> From another point of view the `ICC_Profile` profile has other methods:
>>  * `write(String fileName)` - always throws unspecified `NullPointerException` on `null`
>>  * `write(OutputStream) `  - always throws unspecified `NullPointerException` on `null`
>> 
>> I am not sure we can throw `IllegalArgumentException` from the `write` methods, so the specification for `getInstance(String)` and `getInstance(InputStream)` could be updated to throw NPE on null same as related `write`.
>> 
>> Thoughts?
>
> Sergey Bylokhov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Unify pairs for filenames and streams
>  - Revert "8299333: Unify used exceptions by all variants of ICC_Profile.getInstance(null)"
>    
>    This reverts commit db5cfdc280c00e38949469f9bc6fcb3d06a12716.

I finally got around to reviewing the CSR. You can now finalize it.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 869:

> 867:      */
> 868:     public static ICC_Profile getInstance(String fileName) throws IOException {
> 869:         if (fileName == null) {

The reasons given for IOException seems more appropriate since a null file cannot be opened but I'm sure you  don't think that is the right exception either
I think it might be best to update the spec along with this change to be clear.

src/java.desktop/share/classes/java/awt/color/ICC_Profile.java line 902:

> 900:      */
> 901:     public static ICC_Profile getInstance(InputStream s) throws IOException {
> 902:         if (s == null) {

Same comment here. We should make it clear in the spec.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/11784


From prr at openjdk.org  Fri Feb 24 00:10:04 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Feb 2023 00:10:04 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <CUV8tTI9usmM4UwWWHh1H5g8V81MlfrtlEkU4_kJVIE=.3515d3c6-8859-4024-bb1a-cc63d6aca7ec@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
 <CUV8tTI9usmM4UwWWHh1H5g8V81MlfrtlEkU4_kJVIE=.3515d3c6-8859-4024-bb1a-cc63d6aca7ec@github.com>
Message-ID: <F-Vv1F4GieWuwNRpsF3qEn7MJ2gdMFgBt6x-IIbAgGA=.865839fe-8d19-4adb-9baf-7f105befe53b@github.com>

On Mon, 20 Feb 2023 08:08:22 GMT, SWinxy <duke at openjdk.org> wrote:

> Figured it out. When setting a Component's font to null, it inherits the font from the component tree.

Good to know but ..

> Changing the fallback font type to a FontUIResource in the peers fixes this. 

Sorry, but I don't think we should do this.

FontUIResource  is something devised by Swing, for Swing.
Making AWT components depend on it for the convenience of Swing is backwards.
And I'm quite surprised that WComponentPeer is EVER used by Swing.
AWT components on Windows are heavyweight - and that peer is for them and Swing is lightweight.

Did you actually try all 3 platforms ?

And if a default font prevents the FontUIResource from being installed, how does it get installed the in the first place ? 
Perhaps that first time the component has no peer and it really is null ?

It seems you would have to explicitly track whether the app set the font omn the JComponent rather than using this mechanism .. and if it did not then ignore whatever the font is ??
But I'm guessing and it adds just another bit more risk+complexity to this change.

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

PR: https://git.openjdk.org/jdk/pull/10565


From smarks at openjdk.org  Fri Feb 24 00:16:52 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 24 Feb 2023 00:16:52 GMT
Subject: RFR: 8302513: remove sun.awt.util.IdentityLinkedList [v2]
In-Reply-To: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
References: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
Message-ID: <WeRc_ciBkLUOwkzHfcgg30xbwDdV5LWwxsdspp1dPh0=.b6d0701a-0a0b-488f-97a9-49ba4a0d0ecd@github.com>

> IdentityLinkedList is used in only one place, so it's fairly simple to replace it with IdentityArrayList.

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

 - Merge branch 'master' into JDK-8302513-remove-IdentityLinkedList
 - Replace IdentityLinkedList with IdentityArrayList.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12567/files
  - new: https://git.openjdk.org/jdk/pull/12567/files/6798bed2..2fe572d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12567&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12567&range=00-01

  Stats: 53674 lines in 1168 files changed: 23050 ins; 16195 del; 14429 mod
  Patch: https://git.openjdk.org/jdk/pull/12567.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12567/head:pull/12567

PR: https://git.openjdk.org/jdk/pull/12567


From duke at openjdk.org  Fri Feb 24 01:40:10 2023
From: duke at openjdk.org (SWinxy)
Date: Fri, 24 Feb 2023 01:40:10 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <F-Vv1F4GieWuwNRpsF3qEn7MJ2gdMFgBt6x-IIbAgGA=.865839fe-8d19-4adb-9baf-7f105befe53b@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
 <CUV8tTI9usmM4UwWWHh1H5g8V81MlfrtlEkU4_kJVIE=.3515d3c6-8859-4024-bb1a-cc63d6aca7ec@github.com>
 <F-Vv1F4GieWuwNRpsF3qEn7MJ2gdMFgBt6x-IIbAgGA=.865839fe-8d19-4adb-9baf-7f105befe53b@github.com>
Message-ID: <elVGbVumTEqdwrM321Sc7Wj8N2uemCfSc1nAUQkrP7c=.42f860cf-e223-4266-95d9-6bd993e3a6f2@github.com>

On Fri, 24 Feb 2023 00:07:20 GMT, Phil Race <prr at openjdk.org> wrote:

> And if a default font prevents the FontUIResource from being installed, how does it get installed the in the first place ?
Perhaps that first time the component has no peer and it really is null ?

The font is null when it's created. Calling `getFont` causes it to go up the hierarchy, if it has a parent. The UI looks to be initialized (and thus a font is set) before `getFont` is called.

> FontUIResource is something devised by Swing, for Swing.
Making AWT components depend on it for the convenience of Swing is backwards.

D'oh.

> It seems you would have to explicitly track whether the app set the font omn the JComponent rather than using this mechanism .. and if it did not then ignore whatever the font is ??
But I'm guessing and it adds just another bit more risk+complexity to this change.

Sounds like the path would be to undo my last commit and just put a note in the code.

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

PR: https://git.openjdk.org/jdk/pull/10565


From prr at openjdk.org  Fri Feb 24 05:01:11 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 24 Feb 2023 05:01:11 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <elVGbVumTEqdwrM321Sc7Wj8N2uemCfSc1nAUQkrP7c=.42f860cf-e223-4266-95d9-6bd993e3a6f2@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
 <CUV8tTI9usmM4UwWWHh1H5g8V81MlfrtlEkU4_kJVIE=.3515d3c6-8859-4024-bb1a-cc63d6aca7ec@github.com>
 <F-Vv1F4GieWuwNRpsF3qEn7MJ2gdMFgBt6x-IIbAgGA=.865839fe-8d19-4adb-9baf-7f105befe53b@github.com>
 <elVGbVumTEqdwrM321Sc7Wj8N2uemCfSc1nAUQkrP7c=.42f860cf-e223-4266-95d9-6bd993e3a6f2@github.com>
Message-ID: <sbkw9OI2iKB_85vubR7xkxsptCwzBecmjZMCK7WzYjA=.c0aa9841-b15c-4a70-a504-be404fe7ca31@github.com>

On Fri, 24 Feb 2023 01:37:44 GMT, SWinxy <duke at openjdk.org> wrote:

> > And if a default font prevents the FontUIResource from being installed, how does it get installed the in the first place ?
> > Perhaps that first time the component has no peer and it really is null ?
> 
> The font is null when it's created. Calling `getFont` causes it to go up the hierarchy, if it has a parent. The UI looks to be initialized (and thus a font is set) before `getFont` is called.

That is what I guessed. Accidental or deliberate ? I'd have to spend time to know.

> 
> > FontUIResource is something devised by Swing, for Swing.
> > Making AWT components depend on it for the convenience of Swing is backwards.
> 
> D'oh.
> 
> > It seems you would have to explicitly track whether the app set the font omn the JComponent rather than using this mechanism .. and if it did not then ignore whatever the font is ??
> > But I'm guessing and it adds just another bit more risk+complexity to this change.
> 
> Sounds like the path would be to undo my last commit and just put a note in the code.

But then there'd either be the correct font not installed or something else bad ?
How would a note in the code help ?

Maybe we are going about this all wrong  ? 
Maybe uninstall isn't needed ? 
What are the rules (set by Swing?) for what a L&F should do when installing a UI ?
If it is "if there is a FontUIResource, then feel free to replace it with yours" then may be everything in
this PR (at least about fonts) is un-needed ?

This is code relied upon by tens of thousands of applications written over a period of 25 years.
A change like this is really risky, when you consider that there are probably 10 times more
apps than there are Swing regresssion tests .. and only a few of the regression (and other) tests cover this kind of scenario.

Testing on every platform of every test we have is a bare minimum.

In the end my point is that unless (and until) we see some application complain, these proactive changes are a bad trade-off.

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

PR: https://git.openjdk.org/jdk/pull/10565


From serb at openjdk.org  Fri Feb 24 08:29:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 24 Feb 2023 08:29:07 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v2]
In-Reply-To: <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
 <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
Message-ID: <ajViiiPvBO-o_Sbykus-T8BddHfVmClkqem94WONUsM=.cbfc7713-cb80-44ce-915c-10175d79e749@github.com>

On Thu, 23 Feb 2023 03:22:19 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
>> 
>> Observation:
>> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
>> 
>> Solution:
>> 
>> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
>> 
>> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
>> 
>> Steps to verify:
>> 
>> JBS contains the steps to reproduce the scenario.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 690:

> 688:         if (accessibleContext == null
> 689:             || doc != theEditor.getDocument()) {
> 690:             AccessibleHTML a = new AccessibleHTML(theEditor);

The "AccessibleHTML" internally registers the listener on the editor to update the state/doc. Why that notification does not work and it is necessary to recreate the "AccessibleHTML" here?

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

PR: https://git.openjdk.org/jdk/pull/12707


From serb at openjdk.org  Fri Feb 24 20:11:05 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 24 Feb 2023 20:11:05 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <QKEcXxWR4Dd6FGqr2Jiqcfiv9t5GhwO9Pka5x90WCgI=.c1e150d6-68f3-48ab-986e-d90b909ccb24@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>
 <Mt6Vv2YjMnw1SSrvWkX06N91CWwKnlJu_cPtxhXD7KY=.891d231c-5081-4f4c-88cc-53cbde4df3b5@github.com>
 <Qekkj0igM94vCQHF9RTZRrrDmqBbPGVBN2o3wtUhpIw=.77da8875-992e-4872-9cdf-8bb3b92438cd@github.com>
 <cSyFymNMn888AAQLMbfKb4U4APfb2PaiTv2_bUPtS_8=.bf768e0b-57f9-4d93-b696-b48069a3f9c4@github.com>
 <QKEcXxWR4Dd6FGqr2Jiqcfiv9t5GhwO9Pka5x90WCgI=.c1e150d6-68f3-48ab-986e-d90b909ccb24@github.com>
Message-ID: <40GbCgVXzgSVBR-9C6uPNkZFosGGi2MRQIOXBg9LyRw=.f94d38eb-eb16-4afc-87c0-a099ed471a64@github.com>

On Thu, 23 Feb 2023 23:12:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> I followed the piece of advice in the [JBS comment](https://bugs.openjdk.org/browse/JDK-8300727?focusedCommentId=14560139&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14560139).
>> 
>> If using `System.gc()` is good enough for testing references:
>> 
>> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/ReferenceEnqueue.java#L54-L60
>> 
>> https://github.com/openjdk/jdk/blob/f612dcfebea7ffd4390f833646ad45d6f0ebd04f/test/jdk/java/lang/ref/PhantomReferentClearing.java#L85-L92
>> 
>> Then it should be good enough for this test too.
>> 
>> Perhaps, the same effect could be achieved by causing OOME in a loop. However, using `System.gc()` makes the intention clearer: *run GC*, wait for the phantom reference to be cleared and enqueued.
>> 
>> I can explicitly select a GC: `-XX:+UseG1GC` (default) or `-XX:+UseSerialGC`.
>
> There are lots of tests that rely on System.gc() actually triggering a gc.
> SFAIK all collectors we have today will obey it unless you use
> -XX:+DisableExplicitGC
> If you can make the test work with that then that would be interesting but calling just System.gc() is no worse than all those other tests.

Many client tests generate OOM for that, we have a special Util, see the usage of Util.generateOOME() or various implementation of generateOOME.

If the OOM + sleep(to give the GC a chance to clean the weakrefs in case of slow systems) does not work, then could it be considerred as a GC bug?

>OutOfMemoryError: The Java Virtual Machine implementation has run out of either virtual or physical memory, and the automatic storage manager was unable to reclaim enough memory to satisfy an object creation request.
https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-6.html#jvms-6.3

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

PR: https://git.openjdk.org/jdk/pull/12594


From aivanov at openjdk.org  Fri Feb 24 20:12:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 24 Feb 2023 20:12:07 GMT
Subject: RFR: 8302513: remove sun.awt.util.IdentityLinkedList [v2]
In-Reply-To: <WeRc_ciBkLUOwkzHfcgg30xbwDdV5LWwxsdspp1dPh0=.b6d0701a-0a0b-488f-97a9-49ba4a0d0ecd@github.com>
References: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
 <WeRc_ciBkLUOwkzHfcgg30xbwDdV5LWwxsdspp1dPh0=.b6d0701a-0a0b-488f-97a9-49ba4a0d0ecd@github.com>
Message-ID: <_B6heHkxQf1MPFI9ptlZW--QpgV0AjgmwTEd7Xks8yc=.cd43bad0-31a4-45b3-92a2-c9d3e6870223@github.com>

On Fri, 24 Feb 2023 00:16:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> IdentityLinkedList is used in only one place, so it's fairly simple to replace it with IdentityArrayList.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8302513-remove-IdentityLinkedList
>  - Replace IdentityLinkedList with IdentityArrayList.

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12567


From aivanov at openjdk.org  Fri Feb 24 20:13:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 24 Feb 2023 20:13:07 GMT
Subject: RFR: 8302513: remove sun.awt.util.IdentityLinkedList [v2]
In-Reply-To: <WeRc_ciBkLUOwkzHfcgg30xbwDdV5LWwxsdspp1dPh0=.b6d0701a-0a0b-488f-97a9-49ba4a0d0ecd@github.com>
References: <kdg4gA1u9kkfueHoNzpbT-7QiZk5ruueNyxpTQmLhfc=.62e2a3af-d3fd-451d-9260-3574cc57d563@github.com>
 <WeRc_ciBkLUOwkzHfcgg30xbwDdV5LWwxsdspp1dPh0=.b6d0701a-0a0b-488f-97a9-49ba4a0d0ecd@github.com>
Message-ID: <_B6heHkxQf1MPFI9ptlZW--QpgV0AjgmwTEd7Xks8yc=.6aeb5b38-5d70-4109-b318-c5e3cf17392d@github.com>

On Fri, 24 Feb 2023 00:16:52 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> IdentityLinkedList is used in only one place, so it's fairly simple to replace it with IdentityArrayList.
>
> Stuart Marks has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8302513-remove-IdentityLinkedList
>  - Replace IdentityLinkedList with IdentityArrayList.

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12567


From aivanov at openjdk.org  Fri Feb 24 21:09:03 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 24 Feb 2023 21:09:03 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <40GbCgVXzgSVBR-9C6uPNkZFosGGi2MRQIOXBg9LyRw=.f94d38eb-eb16-4afc-87c0-a099ed471a64@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <WRRsEEnczqudnTze8eoOAD3WF7J9XScgC38EayXhTls=.33aedd95-6140-4e1a-903b-f0d59cbd0683@github.com>
 <Mt6Vv2YjMnw1SSrvWkX06N91CWwKnlJu_cPtxhXD7KY=.891d231c-5081-4f4c-88cc-53cbde4df3b5@github.com>
 <Qekkj0igM94vCQHF9RTZRrrDmqBbPGVBN2o3wtUhpIw=.77da8875-992e-4872-9cdf-8bb3b92438cd@github.com>
 <cSyFymNMn888AAQLMbfKb4U4APfb2PaiTv2_bUPtS_8=.bf768e0b-57f9-4d93-b696-b48069a3f9c4@github.com>
 <QKEcXxWR4Dd6FGqr2Jiqcfiv9t5GhwO9Pka5x90WCgI=.c1e150d6-68f3-48ab-986e-d90b909ccb24@github.com>
 <40GbCgVXzgSVBR-9C6uPNkZFosGGi2MRQIOXBg9LyRw=.f94d38eb-eb16-4afc-87c0-a099ed471a64@github.com>
Message-ID: <Q6cf1eoU0QLyBpzO5OUPWuk3OcdlLA76EvHox6H48ws=.1577db55-1c62-4056-8d7b-8a90a431e2a6@github.com>

On Fri, 24 Feb 2023 20:08:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> There are lots of tests that rely on System.gc() actually triggering a gc.
>> SFAIK all collectors we have today will obey it unless you use
>> -XX:+DisableExplicitGC
>> If you can make the test work with that then that would be interesting but calling just System.gc() is no worse than all those other tests.
>
> Many client tests generate OOM for that, we have a special Util, see the usage of Util.generateOOME() or various implementation of generateOOME.
> 
> If the OOM + sleep(to give the GC a chance to clean the weakrefs in case of slow systems) does not work, then could it be considerred as a GC bug?
> 
>>OutOfMemoryError: The Java Virtual Machine implementation has run out of either virtual or physical memory, and the automatic storage manager was unable to reclaim enough memory to satisfy an object creation request.
> https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-6.html#jvms-6.3

Yes, I saw this method, and [it periodically **calls `System.gc()`**](https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/test/jdk/javax/swing/regtesthelpers/Util.java#L102-L103).

I still don't understand your concern. How is generating `OutOfMemoryError` better than calling `System.gc()`?

Calling `System.gc()` conveys the intent in a clearer way. No OOME is required.

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

PR: https://git.openjdk.org/jdk/pull/12594


From dnguyen at openjdk.org  Fri Feb 24 22:09:03 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 24 Feb 2023 22:09:03 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel
Message-ID: <Rzvr9bzCtDgJUVKYzffMW3SObjeUP_FXjDcrpBqal7s=.19dfed31-4e08-492f-bb7c-06cff617e65c@github.com>

The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).

This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.

This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.

The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.

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

Commit messages:
 - Fix whitespace error
 - Add automated headful test for fix.
 - Update copyright year
 - Modify bounds for border insets

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

PR: https://git.openjdk.org/jdk/pull/12750


From dnguyen at openjdk.org  Fri Feb 24 22:12:03 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 24 Feb 2023 22:12:03 GMT
Subject: RFR: 8302268: Prefer ArrayList to LinkedList in XEmbeddedFramePeer
In-Reply-To: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
References: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
Message-ID: <XVjq1XDDMVF85yWnwVLZzOU95cBLWMKPRyPVmbFUv4o=.79703d1a-b0e4-4383-8e46-839fa3a21f2f@github.com>

On Thu, 9 Feb 2023 09:51:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator/indexOf calls on this list. No removes from the head or something like this. ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

LGTM

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

Marked as reviewed by dnguyen (Author).

PR: https://git.openjdk.org/jdk/pull/12486


From prr at openjdk.org  Sat Feb 25 00:09:09 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 25 Feb 2023 00:09:09 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v4]
In-Reply-To: <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <V5gvpteeBdnxA9CP2GvxRkNWQZkfXc4TwIQRTO4T6Gs=.e3a3c51d-0b29-483e-8bae-14fd12ac65d1@github.com>
Message-ID: <HudHLH6WZqy53Vnx4hdh4zkHzCIPiClbFdAGjuD1I6I=.96dff9de-504a-403b-8435-7a3cf921b1ed@github.com>

On Tue, 29 Nov 2022 10:36:32 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
>> 
>> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
>> 
>> Four rectangles are printed:
>> 1. size 300x100, portrait orientation
>> 2. size 300x100, landscape orientation
>> 3. size 100x300, portrait orientation
>> 4. size 100x300, landscape orientation
>> 
>> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
>> 
>> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
>> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
>> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
>> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
>> 
>> The Cocoa code that shows NSPrintInfo behavior:
>> 
>> #import <Cocoa/Cocoa.h>
>> 
>> int main()
>> {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSApp = [NSApplication sharedApplication];
>> 
>>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>>     #define NS_PORTRAIT NSPaperOrientationPortrait
>>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>>     #else // code for SDK 10.8 or older
>>     #define NS_PORTRAIT NSPortraitOrientation
>>     #define NS_LANDSCAPE NSLandscapeOrientation
>>     #endif
>> 
>>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
>> 
>>     printf("create default print info\n");
>>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>>     NSSize size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("call setUpPrintOperationDefaultValues\n");
>>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     double w = 300.0;
>>     double h = 100.0;
>>     printf("set size: [%f, %f]\n", w, h);
>>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("Set NS_PORTRAIT orientation\n");
>>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     [NSApp run];
>> 
>>     [NSApp release];
>>     [pool release];
>>     return(EXIT_SUCCESS);
>> } 
>> 
>> 
>> On macOS Mojave 10.14.5 it prints:
>> 
>> 
>> NS_PORTRAIT: 0
>> NS_LANDSCAPE: 1
>> create default print info
>> orientation: 0, paper size: [612.000000, 792.000000]
>> call setUpPrintOperationDefaultValues
>> orientation: 0, paper size: [612.000000, 792.000000]
>> set size: [300.000000, 100.000000]
>> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
>> Set NS_PORTRAIT orientation
>> orientation: 0, paper size: [100.000000, 300.000000] // size flip
>> ``` 
>> 
>> There are four possible cases for printing a rectangle with different size and orientation:
>> 1. Input: paper size: (w > h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>>   Note: width and height are swapped
>> 2. Input: paper size: (w > h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
>> 3. Input: paper size: (w < h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
>> 4. Input: paper size: (w < h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>>   Note: width and height are swapped
>> 
>> Only for cases 1 and 4 the final width and height are swapped.
>> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
>> 
>> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
>> Setting requested size leads that subsequent orientation flips width and height.
>> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
>> 
>> Printed rectangles before and after the fix:
>> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
>> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
>> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
>> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
>> 
>> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos in FlipPageFormat class comments

Your test is confusing me. If it confuses me, then I suspect when it is run by anyone from SQE it will confuse them too.
First, why do you need to use A5 ? It makes it hard.
The test should be made so that it works with BOTH A4 and NA_LETTER. 

Next 
P1 says 419x595 PORTRAIT
P4 says 419x595 LANDSCAPE - but looks portrait
Similarly
P2 says 595x419 LANDSCAPE
P3 says 595x419 PORTRAIT - but looks landscape

so they don't match what your instructions say they should be .. leaving me wondering if the code is wrong, the test is wrong, or something I did is wrong.
But your test says things like for P2
 " rectangle with width is less than height, orientation landscape"
but clearly prints width > height.
Similarly backward for P4.

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

PR: https://git.openjdk.org/jdk/pull/10808


From aturbanov at openjdk.org  Sat Feb 25 13:42:10 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 13:42:10 GMT
Subject: Integrated: 8302120: Prefer ArrayList to LinkedList in
 AggregatePainter
In-Reply-To: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
References: <Qt9wkMcq7bb-4QdU5qjmbI7OZEOEdVirXPznmj5yydU=.897a3a20-e675-4ce7-b79a-beffc98366c9@github.com>
Message-ID: <bxjt2b2tDpAsjsAEqbDkwSms2MWUD-8AxzVz55qPgko=.b217b4c7-d0a6-4bbb-b02b-805fabb6c266@github.com>

On Fri, 27 Jan 2023 13:26:28 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator calls on this list. No removes from the head or something like this. Not sure why LinkedList was used, but ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

This pull request has now been integrated.

Changeset: 1dbd18ac
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1dbd18ac634521edd293a570c66d4d1fe092cfef
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8302120: Prefer ArrayList to LinkedList in AggregatePainter

Reviewed-by: serb

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

PR: https://git.openjdk.org/jdk/pull/12254


From aturbanov at openjdk.org  Sat Feb 25 13:43:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 13:43:12 GMT
Subject: Integrated: 8302268: Prefer ArrayList to LinkedList in
 XEmbeddedFramePeer
In-Reply-To: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
References: <iWwkiCKKvqhlhDdU2sT5HYpgcE9GBj5NISeWx8u09vU=.69d3fee3-ef1b-4ed0-b942-db68e514314d@github.com>
Message-ID: <hPNArBqdIBu8WcJXCrP8RuhuICPN40nPqyVLTTZyEWU=.09430883-2c57-49cf-8683-326b3f4d0703@github.com>

On Thu, 9 Feb 2023 09:51:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There is only add/iterator/indexOf calls on this list. No removes from the head or something like this. ArrayList should be preferred as more efficient and widely used (more chances for JIT) collection

This pull request has now been integrated.

Changeset: 2fb1e3b7
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fb1e3b7e72cf7836a9ffd9c6a5b09a6eef3c01b
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8302268: Prefer ArrayList to LinkedList in XEmbeddedFramePeer

Reviewed-by: serb, dnguyen

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

PR: https://git.openjdk.org/jdk/pull/12486


From asemenov at openjdk.org  Sat Feb 25 15:29:21 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sat, 25 Feb 2023 15:29:21 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v4]
In-Reply-To: <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <KMaPkryUkSlIZdpEz7fkT1nAqPTJZIseooxtFBBT4dc=.2d3f244f-7e94-4e97-b932-99cef0c7eaab@github.com>
Message-ID: <JUtBA3wEyntBqeNmZE0AtwP_je8BjEId8GACy73ANRw=.84cb8418-3ade-4281-8dc6-5edba499629a@github.com>

On Wed, 9 Nov 2022 09:42:00 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
>> 
>> @forantar @azuev-java @mrserb please review.
>> 
>> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   We are not using author tags in tests either - but that's just a nitpick.

We will think about solving this problem and try to offer the best.

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

PR: https://git.openjdk.org/jdk/pull/8578


From asemenov at openjdk.org  Sat Feb 25 15:29:23 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Sat, 25 Feb 2023 15:29:23 GMT
Subject: Withdrawn: 8271846 a11y API lacks setSelectedIndex method
In-Reply-To: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
Message-ID: <1U5bJy2I4yU-oAZQpKZKLGRuCEI-K07YF5_iizb-oKM=.37064ec6-bab4-4bdf-b9ed-fe73325f8a65@github.com>

On Fri, 6 May 2022 16:10:35 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> A11Y implementation on macOS has to directly call the 'JList.setSelectedIndex' method in order to request selection on an item (see 'CAccessibility.requestSelection'). The reason is that a11y API lacks appropriate method.There's only 'javax.accessibility.AccessibleSelection#addAccessibleSelection' which is mapped to 'javax.swing.JList#addSelectionInterval', it can not be used to set selected index.
> 
> @forantar @azuev-java @mrserb please review.
> 
> Please note that the new API allows you to implement a multiple selection in lists from the Java side, but I did not succeed in implementing it, because I could not determine the inclusion of the so-called "VoiceOver multiple selection mode".

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/8578


From aturbanov at openjdk.org  Sat Feb 25 17:02:12 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 17:02:12 GMT
Subject: RFR: 8302849: SurfaceManager might expose partially constructed
 object
In-Reply-To: <Ppas5MKQoxJHK8icV5-hsTlihbeF-47uwx2mrtIwB-g=.196f6cc9-4b0e-49a4-9e36-f629d47f0175@github.com>
References: <Ppas5MKQoxJHK8icV5-hsTlihbeF-47uwx2mrtIwB-g=.196f6cc9-4b0e-49a4-9e36-f629d47f0175@github.com>
Message-ID: <c867TXVYnaBFLSLxI8RljuRfaTa02M69j0Ue_n1pi7M=.75eacbc7-9ce2-4bd7-a9be-9103d32f2c30@github.com>

On Mon, 20 Feb 2023 10:25:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add `volatile` to a variable declaration in order to prevent partially initialized objects to be observed by threads.
> 
> `SurfaceManager` is using a lazily initialized cacheMap that is initialized using a double-checked locking mechanism. Generally, objects initialized using such constructs need to be declared volatile. 
> 
> See https://en.wikipedia.org/wiki/Double-checked_locking#Usage_in_Java

Copyright year update seems forgotten.

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

PR: https://git.openjdk.org/jdk/pull/12654


From aturbanov at openjdk.org  Sat Feb 25 17:42:48 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 25 Feb 2023 17:42:48 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable
Message-ID: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>

If CompareAndSwap is not used, then AtomicReference could be replaced with volatile. It simplified code a bit.

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

Commit messages:
 - [PATCH] Avoid AtomicReference in TextComponentPrintable

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

PR: https://git.openjdk.org/jdk/pull/12018


From serb at openjdk.org  Sat Feb 25 17:42:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 25 Feb 2023 17:42:49 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable
In-Reply-To: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
References: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
Message-ID: <iPUoBPHoP3gu98MEtQ7esSSSVFmFPBZpq324i__LoXs=.2cc725b4-6470-4712-862e-dae7b6381ecc@github.com>

On Mon, 16 Jan 2023 20:25:02 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> If CompareAndSwap is not used, then AtomicReference could be replaced with volatile. It simplified code a bit.

Looks fine.

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

PR: https://git.openjdk.org/jdk/pull/12018


From duke at openjdk.org  Sat Feb 25 18:19:05 2023
From: duke at openjdk.org (Brett Okken)
Date: Sat, 25 Feb 2023 18:19:05 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable
In-Reply-To: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
References: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
Message-ID: <7ZP-TfGPj5lpC3vRN_McfximlBJg6eaIpxl6JUWraVU=.39bd04cd-7b7f-4988-9793-80478906690c@github.com>

On Mon, 16 Jan 2023 20:25:02 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> If CompareAndSwap is not used, then AtomicReference could be replaced with volatile. It simplified code a bit.

src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 343:

> 341:                     public FontMetrics getFontMetrics(Font font) {
> 342:                         return (frc == null)
> 343:                             ? super.getFontMetrics(font)

Should the be set to local variable to avoid 2 volatile reads?

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

PR: https://git.openjdk.org/jdk/pull/12018


From serb at openjdk.org  Sun Feb 26 05:25:03 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 26 Feb 2023 05:25:03 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
Message-ID: <gswp9yfP8pTXvvwERLg9LyN-ukuIxQUQsVjnVT_K8F4=.3afbb1d6-62f8-408b-9907-fb0e440ffae3@github.com>

On Thu, 16 Feb 2023 14:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test has become unstable recently, there were quite a few failures, on Windows mostly. I was lucky enough to find a host where the test failed consistently.
> 
> I call `System.gc()` directly as suggested in comments to the bug. I used `PhantomReference` instead of `WeakReference`.
> 
> Now the test calls `System.gc()` in a loop and waits for the reference to be enqueued. In majority of cases, the test exits the loop at the second attempt.

> Yes, I saw this method, and [it periodically calls System.gc()](https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/test/jdk/javax/swing/regtesthelpers/Util.java#L102-L103).

It generates OOM to make sure that gc will be called, unlike System.gc() which per the spec can be ignored.

> I still don't understand your concern. How is generating OutOfMemoryError better than calling System.gc()?

That method uses both, which I suggested doing at the start. It is better to follow one approach than implement different patterns here and there.

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

PR: https://git.openjdk.org/jdk/pull/12594


From aturbanov at openjdk.org  Sun Feb 26 14:55:27 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 26 Feb 2023 14:55:27 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable [v2]
In-Reply-To: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
References: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
Message-ID: <NZ8kabGE-XyZw5Yxb1dm32pL2kfQHaY1Q2FmuZ8QtQc=.943997c4-a798-407b-be56-c1e232c9045a@github.com>

> If CompareAndSwap is not used, then AtomicReference could be replaced with volatile. It simplified code a bit.

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

  8303213: Avoid AtomicReference in TextComponentPrintable
  
  read volatile field only once

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12018/files
  - new: https://git.openjdk.org/jdk/pull/12018/files/b7224447..b9e7bd7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12018&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12018&range=00-01

  Stats: 8 lines in 1 file changed: 6 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12018.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12018/head:pull/12018

PR: https://git.openjdk.org/jdk/pull/12018


From aturbanov at openjdk.org  Sun Feb 26 14:55:27 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 26 Feb 2023 14:55:27 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable [v2]
In-Reply-To: <7ZP-TfGPj5lpC3vRN_McfximlBJg6eaIpxl6JUWraVU=.39bd04cd-7b7f-4988-9793-80478906690c@github.com>
References: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
 <7ZP-TfGPj5lpC3vRN_McfximlBJg6eaIpxl6JUWraVU=.39bd04cd-7b7f-4988-9793-80478906690c@github.com>
Message-ID: <HMs_Sa3wvgjuwGIL0myYS8VawXLKlS5FEmxv8gjAYmQ=.b8fce8a4-c71b-493f-8770-afe482fcef4f@github.com>

On Sat, 25 Feb 2023 18:16:07 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303213: Avoid AtomicReference in TextComponentPrintable
>>   
>>   read volatile field only once
>
> src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 343:
> 
>> 341:                     public FontMetrics getFontMetrics(Font font) {
>> 342:                         return (frc == null)
>> 343:                             ? super.getFontMetrics(font)
> 
> Should the be set to local variable to avoid 2 volatile reads?

I agree, it's better to read once.

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

PR: https://git.openjdk.org/jdk/pull/12018


From abhiscxk at openjdk.org  Mon Feb 27 04:55:04 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 27 Feb 2023 04:55:04 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v2]
In-Reply-To: <ajViiiPvBO-o_Sbykus-T8BddHfVmClkqem94WONUsM=.cbfc7713-cb80-44ce-915c-10175d79e749@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
 <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
 <ajViiiPvBO-o_Sbykus-T8BddHfVmClkqem94WONUsM=.cbfc7713-cb80-44ce-915c-10175d79e749@github.com>
Message-ID: <fh6KaI85UqgdJ4vniORAnqTl-byuGh2XXOBNXWBrK1Q=.be28f33a-4264-441c-8259-43e466e7209f@github.com>

On Fri, 24 Feb 2023 08:26:43 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright year update
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 690:
> 
>> 688:         if (accessibleContext == null
>> 689:             || doc != theEditor.getDocument()) {
>> 690:             AccessibleHTML a = new AccessibleHTML(theEditor);
> 
> The "AccessibleHTML" internally registers the listener on the editor to update the state/doc. Why that notification does not work and it is necessary to recreate the "AccessibleHTML" here?

The "AccessibleHTML" does internally register the listener on the editor to update the state/doc.

But the `rootHTMLAccessibleContext` is not updated/created for the new root element on doc change and when  `getAccessibleChildrenCount` is called it returns the child count 0, because the API is get called on the old object.

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

PR: https://git.openjdk.org/jdk/pull/12707


From psadhukhan at openjdk.org  Mon Feb 27 09:24:17 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Feb 2023 09:24:17 GMT
Subject: Integrated: 8081474: SwingWorker calls 'done' before the
 'doInBackground' is finished
In-Reply-To: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
References: <9EGpST7smKRcCfpBvw8fbwbFV4WMcnsf87Svw4oFA1s=.fc53a43d-05a0-4aaf-beb6-17625ef6fcc8@github.com>
Message-ID: <ALMrK3was3ERY2zQQOzZRP7DjaATvDmPw0JnQuDhzoQ=.4467534b-bf98-4d03-850d-5e249aa59c55@github.com>

On Wed, 11 Jan 2023 11:01:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> SwingWorker done() method [spec ](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L452) says "Executed on the Event Dispatch Thread after the doInBackground method is finished"
> but there's no mechanism in place to honor that claim.
> The [spec](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/SwingWorker.java#L289)
> also says the state should be DONE after doInBackground() returns which is also not done.
> 
> Modified the code to honour the specification.

This pull request has now been integrated.

Changeset: dbb5581e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbb5581eba5d765bca95585ba91f9b0eee9d1f57
Stats:     161 lines in 2 files changed: 152 ins; 6 del; 3 mod

8081474: SwingWorker calls 'done' before the 'doInBackground' is finished

Reviewed-by: aivanov, serb

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

PR: https://git.openjdk.org/jdk/pull/11940


From mickleness at gmail.com  Mon Feb 27 10:10:29 2023
From: mickleness at gmail.com (Jeremy Wood)
Date: Mon, 27 Feb 2023 10:10:29 +0000
Subject: Stage Manager Problems
In-Reply-To: <emc3b9f388-53f2-404a-b4eb-8757cebbcbd6@cecdd4f4.com>
References: <em7c1e413a-5764-4ae1-8853-b1cf1b1e97c9@17fbc042.com>
 <BYAPR10MB3350EEB6F196F7440CF1E9AC80A09@BYAPR10MB3350.namprd10.prod.outlook.com>
 <em7b75128a-93a4-462c-a802-4a1b7a71000f@17fbc042.com>
 <78528704-678e-f117-1af8-83ac93b79365@oracle.com>
 <emc3b9f388-53f2-404a-b4eb-8757cebbcbd6@cecdd4f4.com>
Message-ID: <emc4ab4a5b-6656-4c99-8151-97abbb0fb754@44eb8e0b.com>

FWIW: I wrapped this exploration up by submitting two bug reports: 
9074851, 9074856 .

Regards,
  - Jeremy

------ Original Message ------
>From "Jeremy Wood" <mickleness at gmail.com>
To "Philip Race" <philip.race at oracle.com>; "Harshitha Onkar" 
<harshitha.onkar at oracle.com>
Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
Date 2/18/2023 5:22:25 AM
Subject Re[2]: Stage Manager Problems

>I made a 5 min video here:
>
>https://drive.google.com/file/d/1al0huWBGhdSeqXrNU_if8HpQGOrxFMFH/view?usp=sharing
>
>(I?ll delete this link in a month or two.)
>
>It shows the original complaint, but also around t=3 min it starts to 
>show a worse problem:
>
>If you have Stage Manager active and you iconify a JFrame, the JFrame 
>never returns to a Frame.NORMAL state. (At least not in this simple 
>test.) This leads to major repaint problems.
>
>So? my immediate question is: now what?
>
>Should I take what I have and just submit an openJDK ticket? (Or a 
>separate ticket for each problem?) Is it OK to write a ticket with an 
>undefined expected behavior, or is that something we should try to 
>clarify here first?
>
>Regards,
>  - Jeremy
>
>
>------ Original Message ------
>From "Philip Race" <philip.race at oracle.com>
>To "Jeremy Wood" <mickleness at gmail.com>; "Harshitha Onkar" 
><harshitha.onkar at oracle.com>
>Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
>Date 2/16/2023 1:31:23 PM
>Subject Re: Stage Manager Problems
>
>> >The more I look at this: I?m afraid the crux of this problem is Stage 
>>Manager has introduced a new window state that Java?s AWT architecture 
>>can?t really describe yet. (But I?d love to be proved wrong??)
>>
>>I think you are right. I do not have Ventura to see / test for myself 
>>but everything I am hearing
>>sounds like with Stage Manager active the "minimise" button just 
>>causes a different compositing transform
>>to be applied to the window and adds that gesture blocking overlay to 
>>make it so that it can't see mouse events
>>or presumably receive focus for keyboard events, and the app is 
>>*intentionally* (as in Apple's intention)
>>ignorant of anything having changed in its state.
>>
>>So it is anyone's guess what we can do about this and even if we 
>>should do something  what would it be ..
>>Maybe there's some clue in the latest SDK - ie a new API ?
>>
>>FWIW One of our team members said he tried this mode for 5 mins but 
>>multiple (non-java) apps were
>>so broken in this mode he turned it off again.
>>
>>
>>
>>-phil.
>>
>>
>>On 2/16/23 2:04 AM, Jeremy Wood wrote:
>>>Harshitha,
>>>
>>>Thanks for the suggestions. I think those don?t really resolve the 
>>>problem, though.
>>>
>>>In the original sample program (having only 1 frame) watching the 
>>>keyboard focus could help identify when there?s a change, but if 
>>>there?s a second frame: that second window could retain the focus and 
>>>the first window still can?t answer the question, ?Are you minimized 
>>>now??
>>>
>>>(I have an updated sample program 
>>><https://drive.google.com/file/d/1uzUUDnAlPoHlFdbVgunwpFKvn4Ies-6-/view?usp=sharing> 
>>>here with two frames if anyone?s interested.)
>>>
>>>Further: the window could lose the focus at any time (if a system 
>>>dialog came up), so I don?t think focus should act as a proxy for 
>>>visibility.
>>>
>>>I did find tonight a work-around for our app a few hours ago. We have 
>>>some native code that identifies all visible windows, their bounds 
>>>and their title. If I consult that list: I see a window that matches 
>>>our (sufficiently unique) window title. And its bounds do not at all 
>>>match with what Java says our window?s bounds are. And it is 
>>>positioned so 99% of it overlaps with a window called ?Gesture 
>>>Blocking Overlay?. (All Stage Manager thumbnails appear to have an 
>>>overlay window with this title.) So it?s a very kludgy and brittle 
>>>work around, for for the time being it works.
>>>
>>>This leads me to believe the Mac OS windowing system doesn?t consider 
>>>the frame to be ?hidden?. I think the window remains technically 
>>>visible. And Mac OS knows it has new bounds. But the peer in Java is 
>>>oblivious to the new bounds/state. (I examined the peer LWWindowPeer 
>>>in a debugger: it still thinks the window is visible (technically 
>>>true) and its bounds are unchanged (not true).)
>>>
>>>The more I look at this: I?m afraid the crux of this problem is Stage 
>>>Manager has introduced a new window state that Java?s AWT 
>>>architecture can?t really describe yet. (But I?d love to be proved 
>>>wrong??)
>>>
>>>  - Jeremy
>>>
>>>------ Original Message ------
>>>From "Harshitha Onkar" <harshitha.onkar at oracle.com>
>>>To "Jeremy Wood" <mickleness at gmail.com>
>>>Cc "client-libs-dev at openjdk.org" < client-libs-dev at openjdk.org>
>>>Date 2/16/2023 1:57:56 AM
>>>Subject RE: Stage Manager Problems
>>>
>>>>Hi Jeremy,
>>>>
>>>>
>>>>
>>>>Does any of the following options help in your case to determine 
>>>>whether or not the frame is iconified?
>>>>
>>>>
>>>>
>>>>frame.isActive()
>>>>frame.isFocused()
>>>>frame.isAlwaysOnTop()
>>>>
>>>>
>>>>Thanks & Regards,
>>>>
>>>>Harshitha Onkar
>>>>
>>>>
>>>>
>>>>From: client-libs-dev <client-libs-dev-retn at openjdk.org> On Behalf 
>>>>Of Jeremy Wood
>>>>Sent: Wednesday, February 15, 2023 10:08 PM
>>>>To:client-libs-dev at openjdk.org
>>>>Subject: Stage Manager Problems
>>>>
>>>>
>>>>
>>>>We?re experiencing problems related JFrames while  Stage Manager 
>>>><https://www.computerworld.com/article/3667999/what-is-apple-stage-manager-and-how-is-it-used.html> 
>>>>is active Mac.
>>>>
>>>>
>>>>
>>>>When Stage Manager is active the yellow minimize button on our 
>>>>JFrame?s appears to ?minimize? our app. But as far as our Frame is 
>>>>concerned:
>>>>
>>>>1. Frame.getExtendedState() does not indicate we?re in an ICONIFIED 
>>>>state
>>>>
>>>>2. Frame.isShowing() returns true
>>>>
>>>>3. a java.awt.desktop.AppForegroundListener believes our app is in 
>>>>the foreground.
>>>>
>>>>
>>>>
>>>>We want to identify when we?re in this hidden state. Is there any 
>>>>other property we can consult to help identify this state?
>>>>
>>>>
>>>>
>>>>I?m happy to submit an openjdk ticket if needed, but first I wanted 
>>>>to sanity check that I?m not missing something. (I also tried 
>>>>querying 
>>>><https://bugs.openjdk.org/issues/?jql=text%20~%20%22%5C%22Stage%20Manager%5C%22%22> 
>>>>the openJDK bug database, but didn?t see any hits.)
>>>>
>>>>
>>>>
>>>>I tried rummaging around in Mac-specific classes (like 
>>>>CPlatformWindow), but I didn?t see any promising leads. It?s always 
>>>>possible I missed something, though.
>>>>
>>>>
>>>>
>>>>Attached is a small 200-line demo app.
>>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230227/49563d0c/attachment.htm>

From jdv at openjdk.org  Mon Feb 27 11:59:29 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 27 Feb 2023 11:59:29 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5 only on
 linux-aarch64
Message-ID: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>

Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.

Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.

We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.

With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

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

Commit messages:
 - 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5 only on linux-aarch64

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

PR: https://git.openjdk.org/jdk/pull/12761


From erikj at openjdk.org  Mon Feb 27 15:17:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 27 Feb 2023 15:17:06 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64
In-Reply-To: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
Message-ID: <hCFzL1w5PE8nC5rLLmhVyKpJ92Hn9C3je0Rkzm8G_LI=.e5988211-03ab-4700-b25c-3c74d90c22a4@github.com>

On Mon, 27 Feb 2023 11:49:27 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
> 
> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
> 
> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
> 
> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 132:

> 130:   # that any cleanup of code related to AWT will not change the
> 131:   # generated code and cause performance issues in J2DBench
> 132:   LIBAWT_CFLAGS += -fpic

We compile with `-fPIC` as a standard flag for position independent code (I just verified that LIBAWT also gets this flag today). My understanding is that `-fpic` may result in smaller/faster code. Overriding with `-fpic` seems like its helping here, but the comment needs to be fixed to explain the actual difference and reason.

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

PR: https://git.openjdk.org/jdk/pull/12761


From aivanov at openjdk.org  Mon Feb 27 15:45:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 15:45:16 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <gswp9yfP8pTXvvwERLg9LyN-ukuIxQUQsVjnVT_K8F4=.3afbb1d6-62f8-408b-9907-fb0e440ffae3@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <gswp9yfP8pTXvvwERLg9LyN-ukuIxQUQsVjnVT_K8F4=.3afbb1d6-62f8-408b-9907-fb0e440ffae3@github.com>
Message-ID: <ndKYd9Qyq6DT3gXs5A9j5k_TgWClZHijOg5zbiDbEEc=.f6101929-509d-4cca-adc2-28cbd04a6ffe@github.com>

On Sun, 26 Feb 2023 05:21:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Yes, I saw this method, and [it periodically calls System.gc()](https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/test/jdk/javax/swing/regtesthelpers/Util.java#L102-L103).
> 
> It generates OOM to make sure that gc will be called, unlike System.gc() which per the spec can be ignored.

Can be but it's not ignored, it's respected.

I provided you at least two tests which solely rely on `System.gc()` and they don't fail.

> > I still don't understand your concern. How is generating OutOfMemoryError better than calling System.gc()?
> 
> That method uses both, which I suggested doing at the start.

You didn't suggest, at least explicitly, using `Util.generateOOME`.

Nevertheless, I think generating OOME is *redundant*, it adds another level of complexity and makes the test slower.

The flag `-Xmx100m` can be safely removed from the test now: it doesn't affect how quick the reference object is cleared.

> It is better to follow one approach than implement different patterns here and there.

Perhaps, the time has come to change the approach: ditch generating OOME and just use `System.gc()` . We've always done this, but it doesn't mean it's the best approach, does it?

If the developers write tests to verify `Reference` objects are cleared without generating OOME by relying only on `System.gc()`, I see no reason why client-libs shouldn't follow the same pattern. The old tests which use `Util.generateOOME` could be retrofitted to the new pattern.

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

PR: https://git.openjdk.org/jdk/pull/12594


From dmarkov at openjdk.org  Mon Feb 27 16:03:50 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Mon, 27 Feb 2023 16:03:50 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
Message-ID: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>

Added the section devoted to client UI test which use Robot API

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

Commit messages:
 - 8303130: Document required Accessibility permissions on macOS

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

PR: https://git.openjdk.org/jdk/pull/12772


From alexsch at openjdk.org  Mon Feb 27 16:16:07 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Mon, 27 Feb 2023 16:16:07 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v5]
In-Reply-To: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
Message-ID: <FpAu7HqKLx3d1dXy00tP9WfbtKSvAPS2ZZ0h4dOtoEQ=.d08204c1-f069-4ede-9f04-8d2ca12f28a3@github.com>

> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
> 
> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
> 
> Four rectangles are printed:
> 1. size 300x100, portrait orientation
> 2. size 300x100, landscape orientation
> 3. size 100x300, portrait orientation
> 4. size 100x300, landscape orientation
> 
> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
> 
> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
> 
> The Cocoa code that shows NSPrintInfo behavior:
> 
> #import <Cocoa/Cocoa.h>
> 
> int main()
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>     NSApp = [NSApplication sharedApplication];
> 
>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>     #define NS_PORTRAIT NSPaperOrientationPortrait
>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>     #else // code for SDK 10.8 or older
>     #define NS_PORTRAIT NSPortraitOrientation
>     #define NS_LANDSCAPE NSLandscapeOrientation
>     #endif
> 
>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
> 
>     printf("create default print info\n");
>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>     NSSize size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("call setUpPrintOperationDefaultValues\n");
>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     double w = 300.0;
>     double h = 100.0;
>     printf("set size: [%f, %f]\n", w, h);
>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("Set NS_PORTRAIT orientation\n");
>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     [NSApp run];
> 
>     [NSApp release];
>     [pool release];
>     return(EXIT_SUCCESS);
> } 
> 
> 
> On macOS Mojave 10.14.5 it prints:
> 
> 
> NS_PORTRAIT: 0
> NS_LANDSCAPE: 1
> create default print info
> orientation: 0, paper size: [612.000000, 792.000000]
> call setUpPrintOperationDefaultValues
> orientation: 0, paper size: [612.000000, 792.000000]
> set size: [300.000000, 100.000000]
> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
> Set NS_PORTRAIT orientation
> orientation: 0, paper size: [100.000000, 300.000000] // size flip
> ``` 
> 
> There are four possible cases for printing a rectangle with different size and orientation:
> 1. Input: paper size: (w > h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>   Note: width and height are swapped
> 2. Input: paper size: (w > h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
> 3. Input: paper size: (w < h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
> 4. Input: paper size: (w < h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>   Note: width and height are swapped
> 
> Only for cases 1 and 4 the final width and height are swapped.
> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
> 
> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
> Setting requested size leads that subsequent orientation flips width and height.
> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
> 
> Printed rectangles before and after the fix:
> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
> 
> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)

Alexander Scherbatiy has updated the pull request incrementally with three additional commits since the last revision:

 - Enlarge test Paper and PageFormat text size
 - Use A4 paper size in the test
 - Draw Paper size with PageFormat size on the printed paper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10808/files
  - new: https://git.openjdk.org/jdk/pull/10808/files/261a15fd..fd9532d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=03-04

  Stats: 37 lines in 1 file changed: 16 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10808.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10808/head:pull/10808

PR: https://git.openjdk.org/jdk/pull/10808


From jdv at openjdk.org  Mon Feb 27 16:16:50 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 27 Feb 2023 16:16:50 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
Message-ID: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>

> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
> 
> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
> 
> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
> 
> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Update comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12761/files
  - new: https://git.openjdk.org/jdk/pull/12761/files/0c39e4c3..e8d25674

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/12761


From jdv at openjdk.org  Mon Feb 27 16:16:55 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 27 Feb 2023 16:16:55 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <hCFzL1w5PE8nC5rLLmhVyKpJ92Hn9C3je0Rkzm8G_LI=.e5988211-03ab-4700-b25c-3c74d90c22a4@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <hCFzL1w5PE8nC5rLLmhVyKpJ92Hn9C3je0Rkzm8G_LI=.e5988211-03ab-4700-b25c-3c74d90c22a4@github.com>
Message-ID: <BXAvZyOtkMGqSiENteUtrqW8U6ME33weqLBMv_yPp-g=.fe68e96c-7968-4b57-bd12-f792a3e7d936@github.com>

On Mon, 27 Feb 2023 15:14:22 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 132:
> 
>> 130:   # that any cleanup of code related to AWT will not change the
>> 131:   # generated code and cause performance issues in J2DBench
>> 132:   LIBAWT_CFLAGS += -fpic
> 
> We compile with `-fPIC` as a standard flag for position independent code (I just verified that LIBAWT also gets this flag today). My understanding is that `-fpic` may result in smaller/faster code. Overriding with `-fpic` seems like its helping here, but the comment needs to be fixed to explain the actual difference and reason.

Thanks @erikj79 for your inputs. I have updated the comment to be relevant to the problem it is resolving.

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

PR: https://git.openjdk.org/jdk/pull/12761


From alexsch at openjdk.org  Mon Feb 27 16:32:02 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Mon, 27 Feb 2023 16:32:02 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v6]
In-Reply-To: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
Message-ID: <l1O7BGaQGcH-ky8Dw-8D0bIDbqbFCci-u5hqgO0_yY0=.caede700-4450-4dd5-ad6e-418133bccd3b@github.com>

> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
> 
> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
> 
> Four rectangles are printed:
> 1. size 300x100, portrait orientation
> 2. size 300x100, landscape orientation
> 3. size 100x300, portrait orientation
> 4. size 100x300, landscape orientation
> 
> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
> 
> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
> 
> The Cocoa code that shows NSPrintInfo behavior:
> 
> #import <Cocoa/Cocoa.h>
> 
> int main()
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>     NSApp = [NSApplication sharedApplication];
> 
>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>     #define NS_PORTRAIT NSPaperOrientationPortrait
>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>     #else // code for SDK 10.8 or older
>     #define NS_PORTRAIT NSPortraitOrientation
>     #define NS_LANDSCAPE NSLandscapeOrientation
>     #endif
> 
>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
> 
>     printf("create default print info\n");
>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>     NSSize size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("call setUpPrintOperationDefaultValues\n");
>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     double w = 300.0;
>     double h = 100.0;
>     printf("set size: [%f, %f]\n", w, h);
>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("Set NS_PORTRAIT orientation\n");
>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     [NSApp run];
> 
>     [NSApp release];
>     [pool release];
>     return(EXIT_SUCCESS);
> } 
> 
> 
> On macOS Mojave 10.14.5 it prints:
> 
> 
> NS_PORTRAIT: 0
> NS_LANDSCAPE: 1
> create default print info
> orientation: 0, paper size: [612.000000, 792.000000]
> call setUpPrintOperationDefaultValues
> orientation: 0, paper size: [612.000000, 792.000000]
> set size: [300.000000, 100.000000]
> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
> Set NS_PORTRAIT orientation
> orientation: 0, paper size: [100.000000, 300.000000] // size flip
> ``` 
> 
> There are four possible cases for printing a rectangle with different size and orientation:
> 1. Input: paper size: (w > h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>   Note: width and height are swapped
> 2. Input: paper size: (w > h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
> 3. Input: paper size: (w < h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
> 4. Input: paper size: (w < h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>   Note: width and height are swapped
> 
> Only for cases 1 and 4 the final width and height are swapped.
> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
> 
> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
> Setting requested size leads that subsequent orientation flips width and height.
> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
> 
> Printed rectangles before and after the fix:
> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
> 
> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)

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

  Rename test to PrintContentCutOffTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10808/files
  - new: https://git.openjdk.org/jdk/pull/10808/files/fd9532d9..7f536e13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/10808


From chen.j.patrick at gmail.com  Mon Feb 27 16:39:48 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Mon, 27 Feb 2023 17:39:48 +0100
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
Message-ID: <CANmuJ8uwnH0weSvbLuEVq-PXUbjxsdSQFH=4DWRdjcLyjh3eEQ@mail.gmail.com>

lgtm


Le lun. 27 f?vr. 2023 ? 17:17, Jayathirth D V <jdv at openjdk.org> a ?crit :

> > Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level
> of gcc optimizations from -O1 level for libawt build. This improved our
> J2DBench performance numbers in some options considerably.
> >
> > Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337
> causes difference in generated code by gcc and this is resulting in
> performance regression for bimg_misc-* J2DBench options in our performance
> servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just
> removed unused variables and it is a cleanup task.
> >
> > We can force gcc to generate position independent code by using -fpic
> option.Also i have removed -fgcse-after-reload option for gcc, because this
> is by default covered under -O3 level of optimization introduced under
> https://bugs.openjdk.org/browse/JDK-8264846.
> >
> > With this change bimg_misc-* J2DBench option performance regression is
> resolved and there are no regression in other options of J2DBench or
> SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one
> additional commit since the last revision:
>
>   Update comment
>
> -------------
>
> Changes:
>   - all: https://git.openjdk.org/jdk/pull/12761/files
>   - new: https://git.openjdk.org/jdk/pull/12761/files/0c39e4c3..e8d25674
>
> Webrevs:
>  - full: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=01
>  - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=00-01
>
>   Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
>   Patch: https://git.openjdk.org/jdk/pull/12761.diff
>   Fetch: git fetch https://git.openjdk.org/jdk pull/12761/head:pull/12761
>
> PR: https://git.openjdk.org/jdk/pull/12761
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230227/fba7b1f4/attachment.htm>

From aivanov at openjdk.org  Mon Feb 27 17:38:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 17:38:08 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v3]
In-Reply-To: <sbkw9OI2iKB_85vubR7xkxsptCwzBecmjZMCK7WzYjA=.c0aa9841-b15c-4a70-a504-be404fe7ca31@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <AX66wL62Z3BXvPEaJ9eoTbKTnNscTMPn8eZrIVGL4o4=.17495455-c6e9-48df-982a-592f4afdfeed@github.com>
 <CUV8tTI9usmM4UwWWHh1H5g8V81MlfrtlEkU4_kJVIE=.3515d3c6-8859-4024-bb1a-cc63d6aca7ec@github.com>
 <F-Vv1F4GieWuwNRpsF3qEn7MJ2gdMFgBt6x-IIbAgGA=.865839fe-8d19-4adb-9baf-7f105befe53b@github.com>
 <elVGbVumTEqdwrM321Sc7Wj8N2uemCfSc1nAUQkrP7c=.42f860cf-e223-4266-95d9-6bd993e3a6f2@github.com>
 <sbkw9OI2iKB_85vubR7xkxsptCwzBecmjZMCK7WzYjA=.c0aa9841-b15c-4a70-a504-be404fe7ca31@github.com>
Message-ID: <TrWnUYel5ta7oEzC6FXhPrHKNKWsmQv_cDTZXg-i7js=.29e0c6fe-4a22-4a15-9bf4-1a897191d5d4@github.com>

On Fri, 24 Feb 2023 04:58:12 GMT, Phil Race <prr at openjdk.org> wrote:

> > > And if a default font prevents the FontUIResource from being installed, how does it get installed the in the first place ?
> > > Perhaps that first time the component has no peer and it really is null ?
> > 
> > 
> > The font is null when it's created. Calling `getFont` causes it to go up the hierarchy, if it has a parent. The UI looks to be initialized (and thus a font is set) before `getFont` is called.
> 
> That is what I guessed. Accidental or deliberate ? I'd have to spend time to know.

This is the code of `Component.getFont`:
https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/src/java.desktop/share/classes/java/awt/Component.java#L1912-L1927

Until the UI is shown, there's no heavyweight peer, so the default font doesn't get set.

Even more, a `UI` instance is set from a component constructor:

https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/src/java.desktop/share/classes/javax/swing/JLabel.java#L176-L182

https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/src/java.desktop/share/classes/javax/swing/JPanel.java#L85-L90

Thus, a font is (always) set on a `JComponent` when the constructor is called, the default L&F font would be an instance of `UIResource`.

However, if the font is reset to `null`, the default font (of heavyweight) components / peers comes into play.

The default font gets set in `getGraphics`:

https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/src/java.desktop/windows/classes/sun/awt/windows/WComponentPeer.java#L640-L643

https://github.com/openjdk/jdk/blob/b4ea80731c6c0a0328a9801590ba5b081f08c3bd/src/java.desktop/unix/classes/sun/awt/X11/XWindow.java#L380-L383

> > > FontUIResource is something devised by Swing, for Swing.
> > > Making AWT components depend on it for the convenience of Swing is backwards.
> > 
> > D'oh.

I agree. **AWT should not depend on Swing**.

> > Sounds like the path would be to undo my last commit and just put a note in the code.
> 
> But then there'd either be the correct font not installed or something else bad ?
> How would a note in the code help ?
> 
> Maybe we are going about this all wrong ?
> Maybe uninstall isn't needed ?
> What are the rules (set by Swing?) for what a L&F should do when installing a UI ? If it is "if there is a FontUIResource, then feel free to replace it with yours" then may be everything in this PR (at least about fonts) is un-needed ?

With where the testing led us, I'm inclined to think that the omission of nullifying the font in `uninstallUI` wasn't accidental but rather a deliberate decision.

Yes, a `Font` object gets ?leaked? after `UI` is uninstalled from a `JComponent`. In majority of cases `uninstallUI` is followed by `installUI` for another Look-and-Feel. (Without a UI delegate, any `JComponent` is unusable.) As such, the `Font` object gets replaced with a newer one if the previous one is `UIResource` or remains intact if it's not `UIResource`, which likely means it was explicitly set by an app developer.

The common rule for Swing: if a property is `UIResource`, replace it with a new default; otherwise preserve the property, don't change it. From this point of view, all the properties of a Swing component could remain untouched in `uninstallUI`. At the same time, many properties are reset to `null`.

There are issues where font doesn't get reset even though it should. The latest example that comes to my mind is [JDK-6753661](https://bugs.openjdk.org/browse/JDK-6753661) and #12180. Were there others?

This current bug [JDK-8278620](https://bugs.openjdk.org/browse/JDK-8278620) was submitted as the result of work on [JDK-8277817](https://bugs.openjdk.org/browse/JDK-8277817) and #6603 where an object had been serialized, if I remember correctly, but the serialized form cannot be read because a class is removed in a later version of JDK. (The `java/awt/dnd/BadSerializationTest/BadSerializationTest.java` test seems to do the wrong thing: it reads a serialized version of a Swing object which was saved by a previous version of JDK, which isn't supported and which was [mentioned in the comments](https://github.com/openjdk/jdk/pull/6603#issuecomment-991295599).)

The description of JDK-8278620 states `BasicListUI` correctly uninstalls all its properties, *including the font_. Why is it not affected by the problem we're seeing here where the font gets reset to a non-`ResourceUI` font from the heavyweight peer of the frame?

> This is code relied upon by tens of thousands of applications written over a period of 25 years. A change like this is really risky, when you consider that there are probably 10 times more apps than there are Swing regresssion tests .. and only a few of the regression (and other) tests cover this kind of scenario.
> 
> Testing on every platform of every test we have is a bare minimum.
> 
> In the end my point is that unless (and until) we see some application complain, these proactive changes are a bad trade-off.

Perhaps, font property should be *left untouched* just like it is now. However, resetting the color properties ? foreground and background ? doesn't seem to cause any issues. As such, the scope of this PR could be reduced to adding the `LookAndFeel.uninstallColors` method and using it in UI classes.

As a matter of fact, I ran the client tests with the latest changeset. The set of failing tests [remains the same](https://github.com/openjdk/jdk/pull/10565#issuecomment-1354064460):

* `javax/swing/GraphicsConfigNotifier/StalePreferredSize.java` (on Windows only)
* one closed test;
* one JCK test.

Only the `sanity/client/SwingSet/src/SwingSet2DemoTest.java` test is gone from the list of failures.

So, this hasn't helped.

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

PR: https://git.openjdk.org/jdk/pull/10565


From erikj at openjdk.org  Mon Feb 27 17:58:09 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 27 Feb 2023 17:58:09 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
Message-ID: <_yVCLOV6_nTrJK-y-oxkx5ul2Lz4cg0hh9nZsNhuBNM=.1a444733-2710-4ff4-a609-808a60fc0247@github.com>

On Mon, 27 Feb 2023 16:16:50 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
>> 
>> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
>> 
>> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
>> 
>> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12761


From alexsch at openjdk.org  Mon Feb 27 18:22:10 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Mon, 27 Feb 2023 18:22:10 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v6]
In-Reply-To: <l1O7BGaQGcH-ky8Dw-8D0bIDbqbFCci-u5hqgO0_yY0=.caede700-4450-4dd5-ad6e-418133bccd3b@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <l1O7BGaQGcH-ky8Dw-8D0bIDbqbFCci-u5hqgO0_yY0=.caede700-4450-4dd5-ad6e-418133bccd3b@github.com>
Message-ID: <77YlzkWiLYQFcSHH4tvvTFhoBSQL8QAICISzRrnUfTo=.15f23d24-d19b-4420-adef-b49f4d3cb308@github.com>

On Mon, 27 Feb 2023 16:32:02 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
>> 
>> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
>> 
>> Four rectangles are printed:
>> 1. size 300x100, portrait orientation
>> 2. size 300x100, landscape orientation
>> 3. size 100x300, portrait orientation
>> 4. size 100x300, landscape orientation
>> 
>> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
>> 
>> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
>> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
>> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
>> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
>> 
>> The Cocoa code that shows NSPrintInfo behavior:
>> 
>> #import <Cocoa/Cocoa.h>
>> 
>> int main()
>> {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSApp = [NSApplication sharedApplication];
>> 
>>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>>     #define NS_PORTRAIT NSPaperOrientationPortrait
>>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>>     #else // code for SDK 10.8 or older
>>     #define NS_PORTRAIT NSPortraitOrientation
>>     #define NS_LANDSCAPE NSLandscapeOrientation
>>     #endif
>> 
>>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
>> 
>>     printf("create default print info\n");
>>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>>     NSSize size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("call setUpPrintOperationDefaultValues\n");
>>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     double w = 300.0;
>>     double h = 100.0;
>>     printf("set size: [%f, %f]\n", w, h);
>>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("Set NS_PORTRAIT orientation\n");
>>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     [NSApp run];
>> 
>>     [NSApp release];
>>     [pool release];
>>     return(EXIT_SUCCESS);
>> } 
>> 
>> 
>> On macOS Mojave 10.14.5 it prints:
>> 
>> 
>> NS_PORTRAIT: 0
>> NS_LANDSCAPE: 1
>> create default print info
>> orientation: 0, paper size: [612.000000, 792.000000]
>> call setUpPrintOperationDefaultValues
>> orientation: 0, paper size: [612.000000, 792.000000]
>> set size: [300.000000, 100.000000]
>> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
>> Set NS_PORTRAIT orientation
>> orientation: 0, paper size: [100.000000, 300.000000] // size flip
>> ``` 
>> 
>> There are four possible cases for printing a rectangle with different size and orientation:
>> 1. Input: paper size: (w > h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>>   Note: width and height are swapped
>> 2. Input: paper size: (w > h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
>> 3. Input: paper size: (w < h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
>> 4. Input: paper size: (w < h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>>   Note: width and height are swapped
>> 
>> Only for cases 1 and 4 the final width and height are swapped.
>> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
>> 
>> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
>> Setting requested size leads that subsequent orientation flips width and height.
>> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
>> 
>> Printed rectangles before and after the fix:
>> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
>> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
>> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
>> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
>> 
>> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test to PrintContentCutOffTest

Could you review the updated fix?

Initially A5 paper size was used because if a printer supports both A4 and A5 paper sizes it is possible to orient A5 paper with both ways (horizontally and vertically) in the printer paper tray.
The test is able to reproduce the issue with A4 paper size as well.
The test is updated to use A4 paper size and renamed to PrintContentCutOffTest.

The test drew a message with incorrect size because it used PageFormat size which returns the transformed Paper size.
I have updated the test to draw both the Paper and the PageFormat size.
The test itself uses PageFormat size to get drawn image area. This looks consistent with the [2D Basic Printing Program](https://docs.oracle.com/javase/tutorial/2d/printing/printable.html). The Basic Printing Program uses PageFormat.getImageableX()/Y() values in `print(Graphics g, PageFormat pf, int page)` method and PageFormat.getImageableX()/Y() methods also return transformed Paper.getImageableX()/Y() values.

This is the updated test printed to PDF on macOS with
- [jdk-19 without the fix](https://bugs.openjdk.org/secure/attachment/102808/print-a4-jdk19.pdf)
- [built jdk with the fix](https://bugs.openjdk.org/secure/attachment/102809/print-a4-jdk-fix.pdf)

P3 has portrait orientation with Paper width greater than height
P4 has landscape orientation with Paper width greater than height

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

PR: https://git.openjdk.org/jdk/pull/10808


From aivanov at openjdk.org  Mon Feb 27 18:52:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 18:52:38 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <QZ4iENrRYXUbzM0yYnUaF1kZMxwkysqRQWklkD17t44=.6c5bc8e4-da8a-44e9-bf37-358ff8b5d631@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

doc/testing.md line 616:

> 614: system key shortcuts for various platforms are provided below.
> 615: 
> 616: ##### MacOS

Suggestion:

##### macOS

Shall we spell _macOS_ with lower-case ?m? like Apple does?

doc/testing.md line 648:

> 646: the default operating system settings need to be adjusted for correct work of
> 647: Robot functionality. The detailed steps how to access and update that settings
> 648: for different platforms are provided below.

Suggestion:

Most automated Client UI tests use `Robot` API to control the UI. Usually,
the default operating system settings need to be adjusted for Robot
to work correctly. The detailed steps how to access and update these settings
for different platforms are provided below.

doc/testing.md line 656:

> 654: Privacy & Security; select Accessibility and ensure the following apps are
> 655: allowed to control your computer: `Java` and `Terminal`. If the tests are run
> 656: from an IDE, the IDE should be granted this permission too.

Suggestion:

`Robot` is not permitted to control your Mac by default since
macOS 10.15. To enable it, choose Apple menu > System Settings, click
Privacy & Security, then click Accessibility and ensure the following apps are
allowed to control your computer: *Java* and *Terminal*. If the tests are run
from an IDE, the IDE should be granted this permission too.

I amended the instructions align with [Allow accessibility apps to access your Mac](https://support.apple.com/en-gb/guide/mac-help/mh43185/mac).

Perhaps, ?to allow it? is better than ?to enable it?. Also unsure about ?`Robot` is not *allowed* to control?? instead of ?permitted?.

*Java* and *Terminal* are the names of apps, not part of a command-line, therefore they're shouldn't be rendered in monospace font; using italics suits better to separate the names from regular text (even though it's not required).

doc/testing.md line 664:

> 662: select Registry Editor; navigate to the following key:
> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
> 664: its value is set to 0.

Suggestion:

On Windows there is a delay in focus transfer. Usually it causes automated
UI test failure. To disable the delay, type `regedit` in the Search and then
select Registry Editor; navigate to the following key:
`HKEY_CURRENT_USER\Control Panel\Desktop`; make sure
the `ForegroundLockTimeout` value is set to 0.

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

PR: https://git.openjdk.org/jdk/pull/12772


From aivanov at openjdk.org  Mon Feb 27 19:06:21 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 19:06:21 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable [v2]
In-Reply-To: <NZ8kabGE-XyZw5Yxb1dm32pL2kfQHaY1Q2FmuZ8QtQc=.943997c4-a798-407b-be56-c1e232c9045a@github.com>
References: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
 <NZ8kabGE-XyZw5Yxb1dm32pL2kfQHaY1Q2FmuZ8QtQc=.943997c4-a798-407b-be56-c1e232c9045a@github.com>
Message-ID: <EznX4U9QaQ8znevpx187V87Zf-WgyqW-nrigulhnnQ4=.97285ce6-e105-44b3-8ad5-a4c43027df72@github.com>

On Sun, 26 Feb 2023 14:55:27 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> If CompareAndSwap is not used, then AtomicReference could be replaced with volatile. It simplified code a bit.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303213: Avoid AtomicReference in TextComponentPrintable
>   
>   read volatile field only once

Looks good to me.

src/java.desktop/share/classes/sun/swing/text/TextComponentPrintable.java line 50:

> 48: import java.util.concurrent.FutureTask;
> 49: 
> 50: import javax.swing.*;

Should this wildcard import be expanded to single-class imports?

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

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12018


From aivanov at openjdk.org  Mon Feb 27 19:23:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 19:23:33 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel
In-Reply-To: <Rzvr9bzCtDgJUVKYzffMW3SObjeUP_FXjDcrpBqal7s=.19dfed31-4e08-492f-bb7c-06cff617e65c@github.com>
References: <Rzvr9bzCtDgJUVKYzffMW3SObjeUP_FXjDcrpBqal7s=.19dfed31-4e08-492f-bb7c-06cff617e65c@github.com>
Message-ID: <wo5d32sEB-IOALrjkRwVz8_2lDNRD4MCrjkNMVj0J5I=.cd78a9cf-5338-4416-b08c-37ecc3c11cf0@github.com>

On Fri, 24 Feb 2023 21:54:30 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
> 
> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
> 
> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
> 
> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxPopup.java line 189:

> 187: 
> 188:         int popupBoundsY = comboBox.getBounds().height;
> 189:         if (comboBox.isEditable() && comboBox.getBorder() != null) {

Does it not affect a non-editable combo box with with a border that has large insets?

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 62:

> 60: 
> 61:             for (UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) {
> 62:                 lafName = laf.getName().equals("CDE/Motif") ? "Motif" : laf.getName();

Is it really needed? Is `CDE/Motif` such a bad name that it needs adjusting?

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 89:

> 87:                 // first selection item is in the correct position on screen.
> 88:                 cb1.setSelectedIndex(1);
> 89:                 cb2.setSelectedIndex(1);

These methods should be called on EDT.

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 97:

> 95:             }
> 96:         } catch (Exception e) {
> 97:             e.printStackTrace();

You should not catch the exception but propagate it for jtreg to fail the test if it throws the exception. Otherwise, the test is considered passed even though it may print `Test failed`.

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 117:

> 115:         robot.mouseMove(cb.getLocationOnScreen().x + cb.getWidth()
> 116:                 - BUTTON_OFFSET, cb.getLocationOnScreen().y
> 117:                 + POPUP_OFFSET);

`getLocationOnScreen()`, `getWidth()` should be called on EDT.

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 131:

> 129:             throws InterruptedException, InvocationTargetException {
> 130:         if (c1.getSelectedItem().toString().equals("One")
> 131:                 && c2.getSelectedItem().toString().equals("One")) {

`getSelectedItem` should be called on EDT.

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 135:

> 133:             SwingUtilities.invokeAndWait(() -> frame.dispose());
> 134:         } else {
> 135:             SwingUtilities.invokeAndWait(() -> frame.dispose());

Your `main` method disposes of the frame. You should just move try-finally block into the for-loop over available Look-and-Feels.

test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 139:

> 137:         }
> 138:     }
> 139: }

Please add a new line character to the end of the file.

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

PR: https://git.openjdk.org/jdk/pull/12750


From aivanov at openjdk.org  Mon Feb 27 20:12:27 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 20:12:27 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v28]
In-Reply-To: <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>
Message-ID: <Sz_8KtXekWv148i0Uf_-Kc1Un5Ifh8-Quzh2VhYwR7A=.b993aa4d-8ada-4226-8667-122321dbde36@github.com>

On Sun, 12 Feb 2023 08:59:42 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete configure
>   
>   Delete configure from the pull request.

You should not force-push. The bot provided [the instructions](https://github.com/openjdk/jdk/pull/9825#issuecomment-1417199887) on how to resolve the merge conflict.

What I usually do is:

git checkout master
git pull upstream master
git checkout <branch>
git merge master -m 'Merge master'


If there are conflicts, you have to resolve them and then use `git commit -m 'Merge master'` to commit the changes.

As the last step, push the local changes to your fork by using `git push` (if there's remote tracking branch is correctly set up for the current branch) or `git push origin <branch>`.

The above implies _origin_ is the name of your fork and _upstream_ is the remote for the upstream which is `https://github.com/openjdk/jdk.git` in this case.

> Delete configure from the pull request.

Somehow you removed the `configure` script altogether. You should restore it to the way it is in the _master_ branch.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aturbanov at openjdk.org  Mon Feb 27 20:48:22 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 27 Feb 2023 20:48:22 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable [v3]
In-Reply-To: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
References: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
Message-ID: <QhHAcBulgK3Ant6S--KFqXAHsPUMDWi4gYAhq0l85aY=.f76781f8-033c-436d-9ccb-cf03ff2b308e@github.com>

> If CompareAndSwap is not used, then AtomicReference could be replaced with volatile. It simplified code a bit.

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

  8303213: Avoid AtomicReference in TextComponentPrintable
  
  expand star import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12018/files
  - new: https://git.openjdk.org/jdk/pull/12018/files/b9e7bd7a..229f9107

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12018&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12018&range=01-02

  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12018.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12018/head:pull/12018

PR: https://git.openjdk.org/jdk/pull/12018


From prr at openjdk.org  Mon Feb 27 20:53:15 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Feb 2023 20:53:15 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v6]
In-Reply-To: <l1O7BGaQGcH-ky8Dw-8D0bIDbqbFCci-u5hqgO0_yY0=.caede700-4450-4dd5-ad6e-418133bccd3b@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <l1O7BGaQGcH-ky8Dw-8D0bIDbqbFCci-u5hqgO0_yY0=.caede700-4450-4dd5-ad6e-418133bccd3b@github.com>
Message-ID: <2eEVJlc12ZmxhM8VUBmichv6UwUgZTkEP7ET5kAPRXI=.e7b2a42e-40de-4496-99d0-3db572ed204c@github.com>

On Mon, 27 Feb 2023 16:32:02 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
>> 
>> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
>> 
>> Four rectangles are printed:
>> 1. size 300x100, portrait orientation
>> 2. size 300x100, landscape orientation
>> 3. size 100x300, portrait orientation
>> 4. size 100x300, landscape orientation
>> 
>> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
>> 
>> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
>> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
>> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
>> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
>> 
>> The Cocoa code that shows NSPrintInfo behavior:
>> 
>> #import <Cocoa/Cocoa.h>
>> 
>> int main()
>> {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSApp = [NSApplication sharedApplication];
>> 
>>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>>     #define NS_PORTRAIT NSPaperOrientationPortrait
>>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>>     #else // code for SDK 10.8 or older
>>     #define NS_PORTRAIT NSPortraitOrientation
>>     #define NS_LANDSCAPE NSLandscapeOrientation
>>     #endif
>> 
>>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
>> 
>>     printf("create default print info\n");
>>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>>     NSSize size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("call setUpPrintOperationDefaultValues\n");
>>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     double w = 300.0;
>>     double h = 100.0;
>>     printf("set size: [%f, %f]\n", w, h);
>>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("Set NS_PORTRAIT orientation\n");
>>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     [NSApp run];
>> 
>>     [NSApp release];
>>     [pool release];
>>     return(EXIT_SUCCESS);
>> } 
>> 
>> 
>> On macOS Mojave 10.14.5 it prints:
>> 
>> 
>> NS_PORTRAIT: 0
>> NS_LANDSCAPE: 1
>> create default print info
>> orientation: 0, paper size: [612.000000, 792.000000]
>> call setUpPrintOperationDefaultValues
>> orientation: 0, paper size: [612.000000, 792.000000]
>> set size: [300.000000, 100.000000]
>> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
>> Set NS_PORTRAIT orientation
>> orientation: 0, paper size: [100.000000, 300.000000] // size flip
>> ``` 
>> 
>> There are four possible cases for printing a rectangle with different size and orientation:
>> 1. Input: paper size: (w > h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>>   Note: width and height are swapped
>> 2. Input: paper size: (w > h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
>> 3. Input: paper size: (w < h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
>> 4. Input: paper size: (w < h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>>   Note: width and height are swapped
>> 
>> Only for cases 1 and 4 the final width and height are swapped.
>> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
>> 
>> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
>> Setting requested size leads that subsequent orientation flips width and height.
>> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
>> 
>> Printed rectangles before and after the fix:
>> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
>> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
>> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
>> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
>> 
>> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename test to PrintContentCutOffTest

This is better. 
I have some test instruction improvements to suggest to avoid bug reports
I suggest that for (3) in the test instructions you make the text :

3. Check that 4 printed rectangles (one per page) have fully drawn 8 vertical areas labeled from 1 to 8,
   and that the blue diagonal lines end at the corners of the yellow rectangle.
  [Note: those are the pass/fail criteria. The messages printed in red are only informative and should not be used as a reason to file a bug].

I'm hoping that will avoid any confusion along the lines of "Page 3 says it is portrait but
it looks landscape to me, so I think I will file a bug report".

FWIW my mac's print-to-pdf is only offering Letter .. but it seems to work anyway.

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

PR: https://git.openjdk.org/jdk/pull/10808


From serb at openjdk.org  Mon Feb 27 20:57:29 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Feb 2023 20:57:29 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

doc/testing.html line 621:

> 619: the following apps are allowed to control your computer:
> 620: <code>Java</code> and <code>Terminal</code>. If the tests are run from
> 621: an IDE, the IDE should be granted this permission too.</p>

You can mention the tests which can be used to verify that the UI, sound, etc are configured properly.(it was done somewhere before one test per option)

doc/testing.md line 664:

> 662: select Registry Editor; navigate to the following key:
> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
> 664: its value is set to 0.

Probably it should mention that this is a workaround for the usage of Cygwin:
https://bugs.openjdk.org/browse/CODETOOLS-7901623

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

PR: https://git.openjdk.org/jdk/pull/12772


From serb at openjdk.org  Mon Feb 27 21:00:43 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Feb 2023 21:00:43 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v2]
In-Reply-To: <fh6KaI85UqgdJ4vniORAnqTl-byuGh2XXOBNXWBrK1Q=.be28f33a-4264-441c-8259-43e466e7209f@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
 <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
 <ajViiiPvBO-o_Sbykus-T8BddHfVmClkqem94WONUsM=.cbfc7713-cb80-44ce-915c-10175d79e749@github.com>
 <fh6KaI85UqgdJ4vniORAnqTl-byuGh2XXOBNXWBrK1Q=.be28f33a-4264-441c-8259-43e466e7209f@github.com>
Message-ID: <6XOFWz8H5_oXg0jlJkunerWzgtZ3yUuvkcH8n-Gfbnw=.ee551595-0771-4388-ac1b-0451634ed10c@github.com>

On Mon, 27 Feb 2023 04:51:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/HTMLEditorKit.java line 690:
>> 
>>> 688:         if (accessibleContext == null
>>> 689:             || doc != theEditor.getDocument()) {
>>> 690:             AccessibleHTML a = new AccessibleHTML(theEditor);
>> 
>> The "AccessibleHTML" internally registers the listener on the editor to update the state/doc. Why that notification does not work and it is necessary to recreate the "AccessibleHTML" here?
>
> The "AccessibleHTML" does internally register the listener on the editor to update the state/doc.
> 
> But the `rootHTMLAccessibleContext` is not updated/created for the new root element on doc change and when  `getAccessibleChildrenCount` is called it returns the child count 0, because the API is get called on the old object.

if the "rootHTMLAccessibleContext" depends on the doc then I think it should be updated in that listener at the same moment the doc is replaced. especially taking into account that the "rootElementInfo" is updated already.

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

PR: https://git.openjdk.org/jdk/pull/12707


From serb at openjdk.org  Mon Feb 27 21:03:54 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 27 Feb 2023 21:03:54 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <ndKYd9Qyq6DT3gXs5A9j5k_TgWClZHijOg5zbiDbEEc=.f6101929-509d-4cca-adc2-28cbd04a6ffe@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <gswp9yfP8pTXvvwERLg9LyN-ukuIxQUQsVjnVT_K8F4=.3afbb1d6-62f8-408b-9907-fb0e440ffae3@github.com>
 <ndKYd9Qyq6DT3gXs5A9j5k_TgWClZHijOg5zbiDbEEc=.f6101929-509d-4cca-adc2-28cbd04a6ffe@github.com>
Message-ID: <wmZa7zxbHG0NnWYejx5C9nkZopopBwQ6M1nFIyaM1nM=.5eecca52-cac7-4af9-ab6b-d3f29a3d3179@github.com>

On Mon, 27 Feb 2023 15:42:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Can be but it's not ignored, it's respected.

It could be ignored per the specification.

> Nevertheless, I think generating OOME is redundant, it adds another level of complexity and makes the test slower.

If it is redundant then let's update all other tests which generate OOM right now and prove it. it would be better than having different approaches here and there.

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

PR: https://git.openjdk.org/jdk/pull/12594


From aivanov at openjdk.org  Mon Feb 27 21:12:23 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 21:12:23 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v28]
In-Reply-To: <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>
Message-ID: <n0Vl6s80AGeL92AZFcfTpUz6iy9ZtMLMTuJJvQJqJKU=.d3b23d43-275b-46b9-b27d-960edcc08df0@github.com>

On Sun, 12 Feb 2023 08:59:42 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delete configure
>   
>   Delete configure from the pull request.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1416:

> 1414:             }
> 1415:             // sometimes get specified without leading #
> 1416:             return hexToColor(str);

I can't see the definitions of `parseRGB`, `parseRGBA`, `hexToColor`.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 3780:

> 3778: 
> 3779:     static int baseFontSizeIndex = 3;
> 3780: }

Please preserve the new line char in the end of files.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1019:

> 1017:      * Converts a color string such as "RED",  "rgb(r g b)",
> 1018:      * "rgba(r g b a)" or "#NNN", "#NNNN", "#NNNNNN",
> 1019:      * "#NNNNNNNN" to a Color.

[CSS Color Level 4, The RGB functions](https://www.w3.org/TR/css-color-4/#rgb-functions) specifies that both `rgb` and `rgba` have the same syntax and both accept `<alpha-value>`.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1025:

> 1023:      * and rgb or rgba HTML3.2 strings.
> 1024:      * Otherwise, it will return null.
> 1025:      * This method is case-insensitive.

Suggestion:

     * Note: This will only convert strings which use any of the following:
     * <ul>
     *   <li><a href="https://www.w3.org/TR/css-color-4/#named-colors">named colors</a>,
     *   <li>hex color notation starting with {@code #} followed by 3, 4, 6, or 8 hexadecimal digits,
     *   <li>`rgb()` and `rgba()` functions
     * </ul>
     * as specified by the <a href="https://www.w3.org/TR/css-color-4/">CSS Color Module Level 4</a>.
     * Otherwise, it will return null.
     * <p>
     * This method is case-insensitive.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1027:

> 1025:      * This method is case-insensitive.
> 1026:      * <p>
> 1027:      * The following code defines instances of the same color :

Suggestion:

     * The following code defines instances of the same color:

There should be no space before the colon.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1030:

> 1028:      * {@snippet lang="java" :
> 1029:      *   import java.awt.Color;
> 1030:      *   import javax.swing.text.html.StyleSheet;

Probably, the imports could be omitted for the sake of brevity.

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 62:

> 60:             passed = false;
> 61:             result.append(" [<name-color> keyword(s) missing]");
> 62:         }

Does it make sense to add a couple of named colors, especially from a _more_ extended set?

test/jdk/javax/swing/text/html/CSS/MissingColorNames.java line 70:

> 68:             passed = false;
> 69:             result.append(" [<rgb()> or <rgba()> values not case insensitive]");
> 70:         }

I'd rather see the test demonstrates all the supported syntax for defining color using `rgb()` and `rgba()` functions as well as for `#N+` notations so that we're sure they work as specified by the CSS specification.

It could be split into several test cases which use `StyleSheet.stringToColor` method for parsing.

I know this would look like a unit test than a regression test. Yet you still have to write one to verify your code works as expected, and the unit test has an intrinsic value: if the code is modified for whatever reason, it ensures all the cases still produce the expected result.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Mon Feb 27 21:15:03 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 21:15:03 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
Message-ID: <dWXQHuN0ViKAvbZhH1fvJxDmAH09p5eaL8KTDZS7tmM=.c1109823-9d44-46d3-9cc6-0d786e5d99d9@github.com>

On Mon, 27 Feb 2023 20:54:08 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> doc/testing.html line 621:
> 
>> 619: the following apps are allowed to control your computer:
>> 620: <code>Java</code> and <code>Terminal</code>. If the tests are run from
>> 621: an IDE, the IDE should be granted this permission too.</p>
> 
> You can mention the tests which can be used to verify that the UI, sound, etc are configured properly.(it was done somewhere before one test per option)

It is mentioned on an internal wiki page.

More detailed instructions are available at the [Automated client GUI testing system set up requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements) wiki page of the Client Libraries.

This page should likely link to it.

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

PR: https://git.openjdk.org/jdk/pull/12772


From aivanov at openjdk.org  Mon Feb 27 21:22:43 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 27 Feb 2023 21:22:43 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <wmZa7zxbHG0NnWYejx5C9nkZopopBwQ6M1nFIyaM1nM=.5eecca52-cac7-4af9-ab6b-d3f29a3d3179@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
 <gswp9yfP8pTXvvwERLg9LyN-ukuIxQUQsVjnVT_K8F4=.3afbb1d6-62f8-408b-9907-fb0e440ffae3@github.com>
 <ndKYd9Qyq6DT3gXs5A9j5k_TgWClZHijOg5zbiDbEEc=.f6101929-509d-4cca-adc2-28cbd04a6ffe@github.com>
 <wmZa7zxbHG0NnWYejx5C9nkZopopBwQ6M1nFIyaM1nM=.5eecca52-cac7-4af9-ab6b-d3f29a3d3179@github.com>
Message-ID: <KycKkttRZdaSaJdMt_t-4DIFGl0I4-nMaVFbiQNkBZo=.dbe93ac3-2c23-467c-adb4-794e33d5ae00@github.com>

On Mon, 27 Feb 2023 21:01:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > Can be but it's not ignored, it's respected.
> 
> It could be ignored per the specification.

Yet it's not.

> > Nevertheless, I think generating OOME is redundant, it adds another level of complexity and makes the test slower.
> 
> If it is redundant then let's update all other tests which generate OOM right now and prove it. it would be better than having different approaches here and there.

I would absolutely explore this route and would be happy to update other tests but this is out of scope for this issue. The `java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java` test often fails in the CI, which creates noise. It can be problem-listed, yet I'd rather avoid it by providing a timely fix which resolves the failure.

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

PR: https://git.openjdk.org/jdk/pull/12594


From duke at openjdk.org  Mon Feb 27 21:31:56 2023
From: duke at openjdk.org (ScientificWare)
Date: Mon, 27 Feb 2023 21:31:56 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v28]
In-Reply-To: <Sz_8KtXekWv148i0Uf_-Kc1Un5Ifh8-Quzh2VhYwR7A=.b993aa4d-8ada-4226-8667-122321dbde36@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>
 <Sz_8KtXekWv148i0Uf_-Kc1Un5Ifh8-Quzh2VhYwR7A=.b993aa4d-8ada-4226-8667-122321dbde36@github.com>
Message-ID: <H6TcjNlkMf7i_uOEChq0RYPcdclWkIGdgoqae4TNxr8=.31313772-3444-49f5-950f-95a2220c1b70@github.com>

On Mon, 27 Feb 2023 20:09:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delete configure
>>   
>>   Delete configure from the pull request.
>
>> Delete configure from the pull request.
> 
> Somehow you removed the `configure` script altogether. You should restore it to the way it is in the _master_ branch.

@aivanov-jdk, I applied the bot's recommendations but the configure file has been included in my PR.
I don't know how to restore this file.

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

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Mon Feb 27 21:56:28 2023
From: duke at openjdk.org (ScientificWare)
Date: Mon, 27 Feb 2023 21:56:28 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v29]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
> 
> Adds missing color names, defined by CSS Level 4, in CSS.java :
> CSS Color Module Level 4
> W3C Candidate Recommendation Snapshot, 5 July 2022
> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
> 
> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)

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

  Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
  
  Remove space.
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/db0244d2..7cd3d995

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=27-28

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

PR: https://git.openjdk.org/jdk/pull/9825


From prr at openjdk.org  Mon Feb 27 23:05:09 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Feb 2023 23:05:09 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
Message-ID: <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>

On Mon, 27 Feb 2023 16:16:50 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
>> 
>> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
>> 
>> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
>> 
>> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update comment

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 126:

> 124: # about initializing a declared 'extern' cannot be turned off individually. Only
> 125: # applies to debug builds. This limitation in gcc is tracked in
> 126: # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977

The comment above needs to be moved inside the if block because it only applies to the first setting, not the second.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 130:

> 128:   BUILD_LIBAWT_debug_mem.c_CFLAGS := -w
> 129:   # This option improves performance of FillRect/FillOval in Java2D by 15% for some gcc
> 130:   LIBAWT_CFLAGS += -fpic

So .. acc. to the eval in JBS we can get rid of -fgcse-after-reload because it is implied by -O3
And Erik says -fPIC is implied by -fpic 

So how is -fpic different than -fPIC in a way that helps here ?
So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.
Since we had an unlimited offset table before, then -fpic won't change anything. 
So what's the explanation ?

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

PR: https://git.openjdk.org/jdk/pull/12761


From dnguyen at openjdk.org  Tue Feb 28 00:17:50 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 28 Feb 2023 00:17:50 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v2]
In-Reply-To: <Rzvr9bzCtDgJUVKYzffMW3SObjeUP_FXjDcrpBqal7s=.19dfed31-4e08-492f-bb7c-06cff617e65c@github.com>
References: <Rzvr9bzCtDgJUVKYzffMW3SObjeUP_FXjDcrpBqal7s=.19dfed31-4e08-492f-bb7c-06cff617e65c@github.com>
Message-ID: <D6XwtkVC7H1Teen75qP1shlU_Soxgq3HXN-k2JaKU88=.b2caaee5-9387-478e-b82b-83315233999b@github.com>

> The issue is in Aqua L&F when an editable JComboBox with a border is used. In this case, when the comboBox is clicked for the drop-down menu to show, the drop-down menu appears at the wrong coordinates (blocking the text of the comboBox and making it unreadable).
> 
> This seems to have been the case for a while and a similar issue appeared recently where an editable Aqua JComboBox also had wrong positioning due to having a border.
> 
> This fix checks for a border and modifies the bounds to accommodate the border's size. Then the usual calculations for the comboBox popup works as expected.
> 
> The new headful test creates an editable comboBox with a TitledBorder and with no border. Then, it automatically clicks the comboBox to open the popup, and clicks where the position of the first selectionItem should be. Finally, it checks if the selected item is correct. This is for all L&F's and the test passes on all OS's.

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

  Propagate exceptions. Move methods to EDT.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12750/files
  - new: https://git.openjdk.org/jdk/pull/12750/files/40889528..e8502b72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12750&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12750&range=00-01

  Stats: 74 lines in 1 file changed: 26 ins; 22 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/12750.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12750/head:pull/12750

PR: https://git.openjdk.org/jdk/pull/12750


From dnguyen at openjdk.org  Tue Feb 28 00:17:55 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 28 Feb 2023 00:17:55 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v2]
In-Reply-To: <wo5d32sEB-IOALrjkRwVz8_2lDNRD4MCrjkNMVj0J5I=.cd78a9cf-5338-4416-b08c-37ecc3c11cf0@github.com>
References: <Rzvr9bzCtDgJUVKYzffMW3SObjeUP_FXjDcrpBqal7s=.19dfed31-4e08-492f-bb7c-06cff617e65c@github.com>
 <wo5d32sEB-IOALrjkRwVz8_2lDNRD4MCrjkNMVj0J5I=.cd78a9cf-5338-4416-b08c-37ecc3c11cf0@github.com>
Message-ID: <InaY8NfWHBiZk1Rpe-gYD7VqfbAVElLJ8XGLANBybXw=.2e57523f-d0c3-4a0a-8d76-59b65aace67e@github.com>

On Mon, 27 Feb 2023 19:11:43 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Propagate exceptions. Move methods to EDT.
>
> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 62:
> 
>> 60: 
>> 61:             for (UIManager.LookAndFeelInfo laf : UIManager.getInstalledLookAndFeels()) {
>> 62:                 lafName = laf.getName().equals("CDE/Motif") ? "Motif" : laf.getName();
> 
> Is it really needed? Is `CDE/Motif` such a bad name that it needs adjusting?

This was added because the `/` caused issues while debugging with file paths, but it's no longer needed. Updated

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 89:
> 
>> 87:                 // first selection item is in the correct position on screen.
>> 88:                 cb1.setSelectedIndex(1);
>> 89:                 cb2.setSelectedIndex(1);
> 
> These methods should be called on EDT.

Updated

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 97:
> 
>> 95:             }
>> 96:         } catch (Exception e) {
>> 97:             e.printStackTrace();
> 
> You should not catch the exception but propagate it for jtreg to fail the test if it throws the exception. Otherwise, the test is considered passed even though it may print `Test failed`.

Good point. I propagated the exception and re-tested

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 117:
> 
>> 115:         robot.mouseMove(cb.getLocationOnScreen().x + cb.getWidth()
>> 116:                 - BUTTON_OFFSET, cb.getLocationOnScreen().y
>> 117:                 + POPUP_OFFSET);
> 
> `getLocationOnScreen()`, `getWidth()` should be called on EDT.

Updated. I moved these accessors out of the method and now call them on the EDT and store the value in vars.

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 131:
> 
>> 129:             throws InterruptedException, InvocationTargetException {
>> 130:         if (c1.getSelectedItem().toString().equals("One")
>> 131:                 && c2.getSelectedItem().toString().equals("One")) {
> 
> `getSelectedItem` should be called on EDT.

Same as above

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 135:
> 
>> 133:             SwingUtilities.invokeAndWait(() -> frame.dispose());
>> 134:         } else {
>> 135:             SwingUtilities.invokeAndWait(() -> frame.dispose());
> 
> Your `main` method disposes of the frame. You should just move try-finally block into the for-loop over available Look-and-Feels.

Added to the bottom of the loop

> test/jdk/javax/swing/JComboBox/EditableComboBoxPopupPos.java line 139:
> 
>> 137:         }
>> 138:     }
>> 139: }
> 
> Please add a new line character to the end of the file.

Updated

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

PR: https://git.openjdk.org/jdk/pull/12750


From dnguyen at openjdk.org  Tue Feb 28 00:23:13 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 28 Feb 2023 00:23:13 GMT
Subject: RFR: 8302558: Editable JComboBox 's popup blocks user from seeing
 characters in Acq look and feel [v2]
In-Reply-To: <wo5d32sEB-IOALrjkRwVz8_2lDNRD4MCrjkNMVj0J5I=.cd78a9cf-5338-4416-b08c-37ecc3c11cf0@github.com>
References: <Rzvr9bzCtDgJUVKYzffMW3SObjeUP_FXjDcrpBqal7s=.19dfed31-4e08-492f-bb7c-06cff617e65c@github.com>
 <wo5d32sEB-IOALrjkRwVz8_2lDNRD4MCrjkNMVj0J5I=.cd78a9cf-5338-4416-b08c-37ecc3c11cf0@github.com>
Message-ID: <VEVTEQXzxKY4sGoR21an52hbD2rHKbNWGmbtcS5OWR4=.444e965c-eee4-4753-a20f-253510fcc4ae@github.com>

On Mon, 27 Feb 2023 19:19:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Propagate exceptions. Move methods to EDT.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxPopup.java line 189:
> 
>> 187: 
>> 188:         int popupBoundsY = comboBox.getBounds().height;
>> 189:         if (comboBox.isEditable() && comboBox.getBorder() != null) {
> 
> Does it not affect a non-editable combo box with with a border that has large insets?

In testing, it does also affect this case. In the normal use cases in testing, this editable Aqua comboBox with a TitledBorder seemed to be the only problematic one, but with custom large borders, this seems to also be an issue.

I recently discussed with @lawrence-andrew and learned that in the setBorder doc for JComponent, UI components are not fully supported with borders. It is instead recommended to place the component in a JPanel. I think this is one of those cases, but the fix in this PR fixes the found issue for the case of an editable Aqua comboBox with a border.

If you could give insights on this Lawrence, that'd be appreciated as well.

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

PR: https://git.openjdk.org/jdk/pull/12750


From prr at openjdk.org  Tue Feb 28 00:32:07 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 00:32:07 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
Message-ID: <UZNXIqdRuKy-2WmBt_yJbvUbjxHHmT6iR-k48wDy8Sk=.06cc4334-7da5-436f-814a-86b60bb2dade@github.com>

On Thu, 16 Feb 2023 14:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test has become unstable recently, there were quite a few failures, on Windows mostly. I was lucky enough to find a host where the test failed consistently.
> 
> I call `System.gc()` directly as suggested in comments to the bug. I used `PhantomReference` instead of `WeakReference`.
> 
> Now the test calls `System.gc()` in a loop and waits for the reference to be enqueued. In majority of cases, the test exits the loop at the second attempt.

Marked as reviewed by prr (Reviewer).

I'm OK with the fix.
If the default collector started ignoring System.gc() it would trigger lots of test failures which would make
it a JDK-wide problem to discuss first.

This one test doesn't make things markedly worse, so let's approve it and you can start a discussion on
core-libs-dev about this and perhaps later on hotspot-gc-dev.

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

PR: https://git.openjdk.org/jdk/pull/12594


From prr at openjdk.org  Tue Feb 28 00:43:16 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 00:43:16 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v29]
In-Reply-To: <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
Message-ID: <JD3YmE6DOmxHDkOYZagm8I7XzhohCAUC_J8ZvXYxPSg=.75c709d8-ed63-4d08-9fc0-c79f210b9ccb@github.com>

On Mon, 27 Feb 2023 21:56:28 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
>   
>   Remove space.
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Why is this patch deleting the top-level JDK configure script ????
That needs to be reverted.

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

Changes requested by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9825


From prr at openjdk.org  Tue Feb 28 01:07:22 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 01:07:22 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v13]
In-Reply-To: <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
Message-ID: <Ug-PYcfh1mLKJT4O60SqjwSbxP9H1wUrTs42uEx6w40=.a5f86be5-0b85-4987-9119-bfbc1e9f24aa@github.com>

On Sun, 5 Feb 2023 09:55:27 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.

As noted there, this PR likely needs to be withdrawn and absorbed into https://github.com/openjdk/jdk/pull/9825

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

PR: https://git.openjdk.org/jdk/pull/10317


From prr at openjdk.org  Tue Feb 28 01:07:26 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 01:07:26 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v29]
In-Reply-To: <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
Message-ID: <Jw7qhSMiEl1eeEB5R0YcVFMnmDxp3QwsfbSJyWR-BUA=.97bfd9af-c7a9-4b32-b414-81d9ca8f5889@github.com>

On Mon, 27 Feb 2023 21:56:28 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
>   
>   Remove space.
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1421:

> 1419: 
> 1420:     private static final Map<String, Color> colorNames =
> 1421:         Map.ofEntries(

I think you can make this lazily initialized. As it is, the Map will be created when the class is initialised,
even if you never need it.

src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1019:

> 1017:      * Converts a color string such as "RED",  "rgb(r g b)",
> 1018:      * "rgba(r g b a)" or "#NNN", "#NNNN", "#NNNNNN",
> 1019:      * "#NNNNNNNN" to a Color.

This specification change seems to be dependent on the change in implementation proposed in
https://github.com/openjdk/jdk/pull/10317/
JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color
And BTW if you implemented that change on its own, it would not be spec compliant.

I think it best to WITHDRAW that other PR and absorb it in this PR

Also you should in the doc include the spec link.
spec limits what it will convert. I think

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

PR: https://git.openjdk.org/jdk/pull/9825


From tr at openjdk.org  Tue Feb 28 04:29:04 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 28 Feb 2023 04:29:04 GMT
Subject: RFR: 8300727:
 java/awt/List/ListGarbageCollectionTest/AwtListGarbageCollectionTest.java
 failed with "List wasn't garbage collected"
In-Reply-To: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
References: <Owjp6r6pdlyG6gw0_RwbgT-k-BVm4gqD6_L3MgTjcL8=.badba1ca-7f43-481a-88f4-a7a59313dee9@github.com>
Message-ID: <7VeayFwnLsYPstYhqTO1qWrglY18-tQkk1eb9bDg-3I=.677a67a1-6308-482e-b634-15edd257b2a2@github.com>

On Thu, 16 Feb 2023 14:38:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The test has become unstable recently, there were quite a few failures, on Windows mostly. I was lucky enough to find a host where the test failed consistently.
> 
> I call `System.gc()` directly as suggested in comments to the bug. I used `PhantomReference` instead of `WeakReference`.
> 
> Now the test calls `System.gc()` in a loop and waits for the reference to be enqueued. In majority of cases, the test exits the loop at the second attempt.

Looks good to me.

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

Marked as reviewed by tr (Committer).

PR: https://git.openjdk.org/jdk/pull/12594


From abhiscxk at openjdk.org  Tue Feb 28 06:47:02 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Feb 2023 06:47:02 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v2]
In-Reply-To: <6XOFWz8H5_oXg0jlJkunerWzgtZ3yUuvkcH8n-Gfbnw=.ee551595-0771-4388-ac1b-0451634ed10c@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
 <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
 <ajViiiPvBO-o_Sbykus-T8BddHfVmClkqem94WONUsM=.cbfc7713-cb80-44ce-915c-10175d79e749@github.com>
 <fh6KaI85UqgdJ4vniORAnqTl-byuGh2XXOBNXWBrK1Q=.be28f33a-4264-441c-8259-43e466e7209f@github.com>
 <6XOFWz8H5_oXg0jlJkunerWzgtZ3yUuvkcH8n-Gfbnw=.ee551595-0771-4388-ac1b-0451634ed10c@github.com>
Message-ID: <KH7BrWopjsXgnuGBIe8tM2Da6WBPB8P0J70AIi3PDq8=.b5f06578-60b6-47ac-857e-21b780a8198c@github.com>

On Mon, 27 Feb 2023 20:57:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The "AccessibleHTML" does internally register the listener on the editor to update the state/doc.
>> 
>> But the `rootHTMLAccessibleContext` is not updated/created for the new root element on doc change and when  `getAccessibleChildrenCount` is called it returns the child count 0, because the API is get called on the old object.
>
> if the "rootHTMLAccessibleContext" depends on the doc then I think it should be updated in that listener at the same moment the doc is replaced. especially taking into account that the "rootElementInfo" is updated already.

In that case I think the `rootElementInfo` needs to update for `rootHTMLAccessibleContext` everytime whenever doc change happened.

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

PR: https://git.openjdk.org/jdk/pull/12707


From jdv at openjdk.org  Tue Feb 28 06:50:05 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 28 Feb 2023 06:50:05 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
Message-ID: <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>

On Mon, 27 Feb 2023 23:02:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 130:
> 
>> 128:   BUILD_LIBAWT_debug_mem.c_CFLAGS := -w
>> 129:   # This option improves performance of FillRect/FillOval in Java2D by 15% for some gcc
>> 130:   LIBAWT_CFLAGS += -fpic
> 
> So .. acc. to the eval in JBS we can get rid of -fgcse-after-reload because it is implied by -O3
> And Erik says -fPIC is implied by -fpic 
> 
> So how is -fpic different than -fPIC in a way that helps here ?
> So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.
> Since we had an unlimited offset table before, then -fpic won't change anything. 
> So what's the explanation ?

Thanks @prrace for your inputs.
I dont think -fPIC is implied by -fpic. @erikj79  please clarify.

Difference between -fpic and -fPIC:
1) With -fPIC we have unlimited storage capacity for global offset table and with -fpic on some platforms we have limitation on this size. For aarch64 it is 28k, but in case of x86 size of GOT is unlimited irrespective of -fPIC or -fpic. This is already captured.
2) Also it looks like if we use -fpic option instead of -fPIC we may generate smaller/faster code as mentioned at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html. Looks like in our case, 28k GOT size suffices and we are able to create smaller/faster code for libawt in case of aarch64. This inturn looks to be related to usage of -msmall-data or -mlarge-data flags. -fpic implies -msmall-data and -fPIC implies -mlarge-data while generating code for shared libraries. -msmall-data also talks about data being nearer and easily accessible compared to  -mlarge-data(https://man7.org/linux/man-pages/man1/gcc.1.html)

Also i can make this change specific to aarch64 since we are seeing its effect only on aarch64.

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

PR: https://git.openjdk.org/jdk/pull/12761


From jdv at openjdk.org  Tue Feb 28 06:55:36 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 28 Feb 2023 06:55:36 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v3]
In-Reply-To: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
Message-ID: <iQV2krpbZWIo9qMv7o9Hpa4BokiURJM2XX5OBzxBex8=.cd5fa1bf-5bdd-4d40-a636-a9e0b16a3837@github.com>

> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
> 
> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
> 
> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
> 
> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.

Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:

  Shift comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12761/files
  - new: https://git.openjdk.org/jdk/pull/12761/files/e8d25674..135883db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12761&range=01-02

  Stats: 8 lines in 1 file changed: 4 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12761.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12761/head:pull/12761

PR: https://git.openjdk.org/jdk/pull/12761


From jdv at openjdk.org  Tue Feb 28 06:55:36 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 28 Feb 2023 06:55:36 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
Message-ID: <gPGH5ajauIdjOmbX78IW8tC-tP2hwf4YmsfEZpPFp2I=.aa236871-a050-455b-afc8-1e0b01c352bd@github.com>

On Mon, 27 Feb 2023 22:58:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update comment
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 126:
> 
>> 124: # about initializing a declared 'extern' cannot be turned off individually. Only
>> 125: # applies to debug builds. This limitation in gcc is tracked in
>> 126: # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45977
> 
> The comment above needs to be moved inside the if block because it only applies to the first setting, not the second.

Updated

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

PR: https://git.openjdk.org/jdk/pull/12761


From abhiscxk at openjdk.org  Tue Feb 28 07:25:29 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Feb 2023 07:25:29 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v3]
In-Reply-To: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
Message-ID: <jNJNgyeixG8iQ-EUIEK2tzBB2f6hQFKVLFGqS8MVWLA=.1948ff17-718a-44ca-8f7e-35ec61427181@github.com>

> JAccessWalker was not able to show component tree correctly if we switch pages for HTML content. 
> 
> Observation:
> The issue observed is that the children are not reported correct for root element when switching of pages happened. The reason behind it is that the `getAccessibleChildrenCount` API is called on the old `accessibleContext` object which return the children count as 0. Whenever we switch the page the children count is recalculated based on the root element but the `accessibleContext `object used to retrieve the child remains unchanged and due to that it return the children count 0.
> 
> Solution:
> 
> Added a condition check to create a new `accessibleContext `object to find out the children count correctly whenever we switch the pages in JEditorPane. 
> 
> Checked with the SwingSet2 JEditorPane demo and it reports well the component tree in JAccessWalker.
> 
> Steps to verify:
> 
> JBS contains the steps to reproduce the scenario.

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

  Review comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12707/files
  - new: https://git.openjdk.org/jdk/pull/12707/files/1bf80092..1e8b0bd6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12707&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12707&range=01-02

  Stats: 19 lines in 3 files changed: 7 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12707.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12707/head:pull/12707

PR: https://git.openjdk.org/jdk/pull/12707


From abhiscxk at openjdk.org  Tue Feb 28 07:30:04 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 28 Feb 2023 07:30:04 GMT
Subject: RFR: 8273986: JEditorPane HTML Demo - Accessibility issues [v2]
In-Reply-To: <6XOFWz8H5_oXg0jlJkunerWzgtZ3yUuvkcH8n-Gfbnw=.ee551595-0771-4388-ac1b-0451634ed10c@github.com>
References: <RJ69mcMU442vfI3xg9iUKEaf6KYRMyLe2wHpKsyO5D0=.97d9c62b-a724-48b6-9502-ccca1cdf2541@github.com>
 <LuMRooDWu3IPB8X4tQvACSQ_QPYW8ErIsnmHe22hO-4=.8e28df13-21f8-4e2f-932e-6eed63e65583@github.com>
 <ajViiiPvBO-o_Sbykus-T8BddHfVmClkqem94WONUsM=.cbfc7713-cb80-44ce-915c-10175d79e749@github.com>
 <fh6KaI85UqgdJ4vniORAnqTl-byuGh2XXOBNXWBrK1Q=.be28f33a-4264-441c-8259-43e466e7209f@github.com>
 <6XOFWz8H5_oXg0jlJkunerWzgtZ3yUuvkcH8n-Gfbnw=.ee551595-0771-4388-ac1b-0451634ed10c@github.com>
Message-ID: <7O-jTN0mbKniXVuuK5vlBuTyWeoa_OuxmneDofegHoo=.20ae09c3-b21f-44ae-950b-6fa32df6cabf@github.com>

On Mon, 27 Feb 2023 20:57:35 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The "AccessibleHTML" does internally register the listener on the editor to update the state/doc.
>> 
>> But the `rootHTMLAccessibleContext` is not updated/created for the new root element on doc change and when  `getAccessibleChildrenCount` is called it returns the child count 0, because the API is get called on the old object.
>
> if the "rootHTMLAccessibleContext" depends on the doc then I think it should be updated in that listener at the same moment the doc is replaced. especially taking into account that the "rootElementInfo" is updated already.

@mrserb  The `elementInfo` variable is updated for `rootHTMLAccessibleContext` while setting up the `rootElementInfo` on doc change.
 It does report the children correctly and as of now there is no need to re-create the accessibleContext everytime on doc change.

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

PR: https://git.openjdk.org/jdk/pull/12707


From dmarkov at openjdk.org  Tue Feb 28 11:03:41 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:41 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>

> Added the section devoted to client UI test which use Robot API

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

  Fix review findings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12772/files
  - new: https://git.openjdk.org/jdk/pull/12772/files/1774d37a..e1ec5f9e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=00-01

  Stats: 40 lines in 2 files changed: 8 ins; 0 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/12772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12772/head:pull/12772

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:41 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:41 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <fnTQ2BBCx8-dOddhwfLDMRWn6qkSvUO76fPk15W4Zjg=.b5ed2cb0-427e-4b4c-bf03-40da37edf2d9@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

@aivanov-jdk @mrserb Thanks for review. I have updated the text based on your suggestions. Please have a look at the new version.

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

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:42 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:42 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <dWXQHuN0ViKAvbZhH1fvJxDmAH09p5eaL8KTDZS7tmM=.c1109823-9d44-46d3-9cc6-0d786e5d99d9@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
 <dWXQHuN0ViKAvbZhH1fvJxDmAH09p5eaL8KTDZS7tmM=.c1109823-9d44-46d3-9cc6-0d786e5d99d9@github.com>
Message-ID: <3Jm3v2Vktc0LRQU72wnjTcnu_706DgO7GQaN_49dBLQ=.d106ef06-c373-428d-b862-3a68c9efa134@github.com>

On Mon, 27 Feb 2023 21:11:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> doc/testing.html line 621:
>> 
>>> 619: the following apps are allowed to control your computer:
>>> 620: <code>Java</code> and <code>Terminal</code>. If the tests are run from
>>> 621: an IDE, the IDE should be granted this permission too.</p>
>> 
>> You can mention the tests which can be used to verify that the UI, sound, etc are configured properly.(it was done somewhere before one test per option)
>
> It is mentioned on an internal wiki page.
> 
> More detailed instructions are available at the [Automated client GUI testing system set up requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements) wiki page of the Client Libraries.
> 
> This page should likely link to it.

I have added the link to the wiki

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

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:42 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:42 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <QZ4iENrRYXUbzM0yYnUaF1kZMxwkysqRQWklkD17t44=.6c5bc8e4-da8a-44e9-bf37-358ff8b5d631@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <QZ4iENrRYXUbzM0yYnUaF1kZMxwkysqRQWklkD17t44=.6c5bc8e4-da8a-44e9-bf37-358ff8b5d631@github.com>
Message-ID: <tlrdS2ZvYrjmdCU-3oGe0ad6OKS-Hk_FXYP2wtOYyvg=.fc38f38c-107d-4fa6-8f14-fffff2b1fe45@github.com>

On Mon, 27 Feb 2023 18:49:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review findings
>
> doc/testing.md line 616:
> 
>> 614: system key shortcuts for various platforms are provided below.
>> 615: 
>> 616: ##### MacOS
> 
> Suggestion:
> 
> ##### macOS
> 
> Shall we spell _macOS_ with lower-case ?m? like Apple does?

Done

> doc/testing.md line 648:
> 
>> 646: the default operating system settings need to be adjusted for correct work of
>> 647: Robot functionality. The detailed steps how to access and update that settings
>> 648: for different platforms are provided below.
> 
> Suggestion:
> 
> Most automated Client UI tests use `Robot` API to control the UI. Usually,
> the default operating system settings need to be adjusted for Robot
> to work correctly. The detailed steps how to access and update these settings
> for different platforms are provided below.

Fixed

> doc/testing.md line 656:
> 
>> 654: Privacy & Security; select Accessibility and ensure the following apps are
>> 655: allowed to control your computer: `Java` and `Terminal`. If the tests are run
>> 656: from an IDE, the IDE should be granted this permission too.
> 
> Suggestion:
> 
> `Robot` is not permitted to control your Mac by default since
> macOS 10.15. To enable it, choose Apple menu > System Settings, click
> Privacy & Security, then click Accessibility and ensure the following apps are
> allowed to control your computer: *Java* and *Terminal*. If the tests are run
> from an IDE, the IDE should be granted this permission too.
> 
> I amended the instructions align with [Allow accessibility apps to access your Mac](https://support.apple.com/en-gb/guide/mac-help/mh43185/mac).
> 
> Perhaps, ?to allow it? is better than ?to enable it?. Also unsure about ?`Robot` is not *allowed* to control?? instead of ?permitted?.
> 
> *Java* and *Terminal* are the names of apps, not part of a command-line, therefore they're shouldn't be rendered in monospace font; using italics suits better to separate the names from regular text (even though it's not required).

Fixed

> doc/testing.md line 664:
> 
>> 662: select Registry Editor; navigate to the following key:
>> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
>> 664: its value is set to 0.
> 
> Suggestion:
> 
> On Windows there is a delay in focus transfer. Usually it causes automated
> UI test failure. To disable the delay, type `regedit` in the Search and then
> select Registry Editor; navigate to the following key:
> `HKEY_CURRENT_USER\Control Panel\Desktop`; make sure
> the `ForegroundLockTimeout` value is set to 0.

Fixed

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

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 11:03:42 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 11:03:42 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
Message-ID: <7lHleflYaOFpVAE9BmAr74Bx9nPlP1JenM8_rY5_BuI=.347a98a3-0ba8-48ed-8a35-9f1d22d3fac7@github.com>

On Mon, 27 Feb 2023 20:52:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review findings
>
> doc/testing.md line 664:
> 
>> 662: select Registry Editor; navigate to the following key:
>> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`; make sure
>> 664: its value is set to 0.
> 
> Probably it should mention that this is a workaround for the usage of Cygwin:
> https://bugs.openjdk.org/browse/CODETOOLS-7901623

Done

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

PR: https://git.openjdk.org/jdk/pull/12772


From chen.j.patrick at gmail.com  Tue Feb 28 13:35:42 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Tue, 28 Feb 2023 14:35:42 +0100
Subject: RFR: 8303130: Document required Accessibility permissions on
 macOS [v2]
In-Reply-To: <7lHleflYaOFpVAE9BmAr74Bx9nPlP1JenM8_rY5_BuI=.347a98a3-0ba8-48ed-8a35-9f1d22d3fac7@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <BAWzhsW7BxdfWqcEKtu8ixHG0U25XlwltyTXYMPGDvI=.10885fc2-bf99-4a84-96ff-0a9fb40467b4@github.com>
 <7lHleflYaOFpVAE9BmAr74Bx9nPlP1JenM8_rY5_BuI=.347a98a3-0ba8-48ed-8a35-9f1d22d3fac7@github.com>
Message-ID: <CANmuJ8tRCnxufnAX+oQYwK=7Q4NQuy2DCW7Yf+q5E0sr-feTSw@mail.gmail.com>

pre submit tests failed

Le mar. 28 f?vr. 2023 ? 12:04, Dmitry Markov <dmarkov at openjdk.org> a ?crit :

> On Mon, 27 Feb 2023 20:52:52 GMT, Sergey Bylokhov <serb at openjdk.org>
> wrote:
>
> >> Dmitry Markov has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Fix review findings
> >
> > doc/testing.md line 664:
> >
> >> 662: select Registry Editor; navigate to the following key:
> >> 663: `HKEY_CURRENT_USER\Control Panel\Desktop\ForegroundLockTimeout`;
> make sure
> >> 664: its value is set to 0.
> >
> > Probably it should mention that this is a workaround for the usage of
> Cygwin:
> > https://bugs.openjdk.org/browse/CODETOOLS-7901623
>
> Done
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12772
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230228/b0b2e8bf/attachment.htm>

From erikj at openjdk.org  Tue Feb 28 14:00:16 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Feb 2023 14:00:16 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
 <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>
Message-ID: <9oErSGZO2hcusvCEEV2eJTgmev_v-5OJclGdyyLwPJg=.2f44899a-2a76-42c1-bde7-b180c5b991ef@github.com>

On Tue, 28 Feb 2023 06:47:37 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 130:
>> 
>>> 128:   BUILD_LIBAWT_debug_mem.c_CFLAGS := -w
>>> 129:   # This option improves performance of FillRect/FillOval in Java2D by 15% for some gcc
>>> 130:   LIBAWT_CFLAGS += -fpic
>> 
>> So .. acc. to the eval in JBS we can get rid of -fgcse-after-reload because it is implied by -O3
>> And Erik says -fPIC is implied by -fpic 
>> 
>> So how is -fpic different than -fPIC in a way that helps here ?
>> So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.
>> Since we had an unlimited offset table before, then -fpic won't change anything. 
>> So what's the explanation ?
>
> Thanks @prrace for your inputs.
> I dont think -fPIC is implied by -fpic. @erikj79  please clarify.
> 
> Difference between -fpic and -fPIC:
> 1) With -fPIC we have unlimited storage capacity for global offset table and with -fpic on some platforms we have limitation on this size. For aarch64 it is 28k, but in case of x86 size of GOT is unlimited irrespective of -fPIC or -fpic. This is already captured.
> 2) Also it looks like if we use -fpic option instead of -fPIC we may generate smaller/faster code as mentioned at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html. Looks like in our case, 28k GOT size suffices and we are able to create smaller/faster code for libawt in case of aarch64. This inturn looks to be related to usage of -msmall-data or -mlarge-data flags. -fpic implies -msmall-data and -fPIC implies -mlarge-data while generating code for shared libraries. -msmall-data also talks about data being nearer and easily accessible compared to  -mlarge-data(https://man7.org/linux/man-pages/man1/gcc.1.html)
> 
> Also i can make this change specific to aarch64 since we are seeing its effect only on aarch64.

I think you have read more about the differences between -fpic and -fPIC than I have, so nothing I can add here.

Making this option only on aarch64 seems like a reasonable idea if that's where we see the effect.

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

PR: https://git.openjdk.org/jdk/pull/12761


From erikj at openjdk.org  Tue Feb 28 14:03:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Feb 2023 14:03:17 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
Message-ID: <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>

On Tue, 28 Feb 2023 11:03:41 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix review findings

doc/testing.md line 666:

> 664: the `ForegroundLockTimeout` value is set to 0.
> 665: 
> 666: Additional information about Client UI tests configuration for vrious operating

Suggestion:

Additional information about Client UI tests configuration for various operating

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

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 14:17:11 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 14:17:11 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>

> Added the section devoted to client UI test which use Robot API

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12772/files
  - new: https://git.openjdk.org/jdk/pull/12772/files/e1ec5f9e..1ce9b932

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12772/head:pull/12772

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 14:17:16 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 14:17:16 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v2]
In-Reply-To: <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
 <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>
Message-ID: <2tEkfzVYky3Z-OFDWk359U64nLZuVMS7yg5zzU3uZ1s=.5fe538b7-f4e7-4b72-94d1-333bca1816fb@github.com>

On Tue, 28 Feb 2023 14:00:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix review findings
>
> doc/testing.md line 666:
> 
>> 664: the `ForegroundLockTimeout` value is set to 0.
>> 665: 
>> 666: Additional information about Client UI tests configuration for vrious operating
> 
> Suggestion:
> 
> Additional information about Client UI tests configuration for various operating

Fixed

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

PR: https://git.openjdk.org/jdk/pull/12772


From chen.j.patrick at gmail.com  Tue Feb 28 15:23:16 2023
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Tue, 28 Feb 2023 16:23:16 +0100
Subject: RFR: 8303130: Document required Accessibility permissions on
 macOS [v2]
In-Reply-To: <2tEkfzVYky3Z-OFDWk359U64nLZuVMS7yg5zzU3uZ1s=.5fe538b7-f4e7-4b72-94d1-333bca1816fb@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <pwaZHeijERVBa5G6joOBgZP6rqRXZFOTPFi2y3cVi-A=.110a9e84-6894-4482-be26-321133f07a14@github.com>
 <cQTyIKyCrpidBC_8P011yzgAiS-erhjLdEAuwqPcoGU=.ebe11442-ce03-48cf-b273-a9d501d2020d@github.com>
 <2tEkfzVYky3Z-OFDWk359U64nLZuVMS7yg5zzU3uZ1s=.5fe538b7-f4e7-4b72-94d1-333bca1816fb@github.com>
Message-ID: <CANmuJ8sL2d5+O61jh5hHoOfSfjz=Wo1GzL2NMheAgV6oZRQU1A@mail.gmail.com>

lgtm


Le mar. 28 f?vr. 2023 ? 15:18, Dmitry Markov <dmarkov at openjdk.org> a ?crit :

> On Tue, 28 Feb 2023 14:00:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:
>
> >> Dmitry Markov has updated the pull request incrementally with one
> additional commit since the last revision:
> >>
> >>   Fix review findings
> >
> > doc/testing.md line 666:
> >
> >> 664: the `ForegroundLockTimeout` value is set to 0.
> >> 665:
> >> 666: Additional information about Client UI tests configuration for
> vrious operating
> >
> > Suggestion:
> >
> > Additional information about Client UI tests configuration for various
> operating
>
> Fixed
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/12772
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20230228/b2b25764/attachment.htm>

From aivanov at openjdk.org  Tue Feb 28 15:34:50 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 15:34:50 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v29]
In-Reply-To: <Jw7qhSMiEl1eeEB5R0YcVFMnmDxp3QwsfbSJyWR-BUA=.97bfd9af-c7a9-4b32-b414-81d9ca8f5889@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
 <Jw7qhSMiEl1eeEB5R0YcVFMnmDxp3QwsfbSJyWR-BUA=.97bfd9af-c7a9-4b32-b414-81d9ca8f5889@github.com>
Message-ID: <vYjN9Ri9rQu-W6zVuseXjrbjQwX4XTYtZOUYb6vWOIQ=.45f6b4cb-464a-418d-8ae0-7c5d47c82b8e@github.com>

On Tue, 28 Feb 2023 01:03:59 GMT, Phil Race <prr at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
>>   
>>   Remove space.
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1019:
> 
>> 1017:      * Converts a color string such as "RED",  "rgb(r g b)",
>> 1018:      * "rgba(r g b a)" or "#NNN", "#NNNN", "#NNNNNN",
>> 1019:      * "#NNNNNNNN" to a Color.
> 
> This specification change seems to be dependent on the change in implementation proposed in
> https://github.com/openjdk/jdk/pull/10317/
> JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color
> And BTW if you implemented that change on its own, it would not be spec compliant.
> 
> I think it best to WITHDRAW that other PR and absorb it in this PR
> 
> Also you should in the doc include the spec link.
> spec limits what it will convert. I think

Initially, it looked as if handling these issues separately was a good idea. Now that we know that the specification of a public needs updating, which requires a CSR, it is better to have everything ready: named colors, hex-parsers, rgb() and rgba() parsers. The spec refers to all the cases. If one is missing, the method is not compliant to its specification.

Amending the implementation one by one would require updating the spec and reviewing the CSR. Thus, having everything ready in one larger PR makes more sense.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Tue Feb 28 15:49:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 15:49:38 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v28]
In-Reply-To: <H6TcjNlkMf7i_uOEChq0RYPcdclWkIGdgoqae4TNxr8=.31313772-3444-49f5-950f-95a2220c1b70@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>
 <Sz_8KtXekWv148i0Uf_-Kc1Un5Ifh8-Quzh2VhYwR7A=.b993aa4d-8ada-4226-8667-122321dbde36@github.com>
 <H6TcjNlkMf7i_uOEChq0RYPcdclWkIGdgoqae4TNxr8=.31313772-3444-49f5-950f-95a2220c1b70@github.com>
Message-ID: <WjMa-ICDu_UBLy8uJrMEbBzSEr2mmOYKa-lqQbrkpYA=.36c3a14c-a4e0-4d94-a490-8422945b677b@github.com>

On Mon, 27 Feb 2023 21:28:38 GMT, ScientificWare <duke at openjdk.org> wrote:

> I applied the bot's recommendations but the configure file has been included in my PR.

I can't know what you really did.

If you applied changes to the branch via GitHub interface here, you have to pull those changes into your local branch ? otherwise they'll diverge and will require merging.

It's probably what happened. If you followed the bot instructions, there should be no need for force-push. After you pushed your branch, should not rebase your branch ? only merge changes from upstream master.

> I don't know how to restore this file.

@scientificware, here's what [the answer on Stack Overflow](https://stackoverflow.com/a/610315/572834) suggest:


git show master:configure >configure

You'll need to add it to the index and commit:

git add configure
git commit -m 'Restore configure'


Alternatively, 

git restore -s master --staged --worktree -- configure


[Another answer](https://stackoverflow.com/a/2364223/572834) which describes the same commands.

Don't forget to push your changes.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Tue Feb 28 15:52:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 15:52:46 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v29]
In-Reply-To: <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <SwAKLagGW8VPslD_1t9FFzL1HySuC2UZZxLGT1pmqXU=.30059f82-a6db-4320-a6fd-fdb2c6d459fa@github.com>
Message-ID: <TpHg0pH5RMMPMHTEzV4djAkl8EXh2YGm31VvGLcnaPg=.5564c170-ba89-4682-94b9-be2a561a6ec6@github.com>

On Mon, 27 Feb 2023 21:56:28 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Add named colors from CSS Color Module Level 4](https://bugs.openjdk.java.net/browse/JDK-8292276)
>> 
>> Adds missing color names, defined by CSS Level 4, in CSS.java :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [7.1 Named Colors](https://www.w3.org/TR/css-color-4/#named-color)
>> 
>> Designed from : [ScientificWare JDK-8292276 : Add named colors from CSS Color Module Level 4](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java
>   
>   Remove space.
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Changes requested by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Tue Feb 28 15:52:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 15:52:51 GMT
Subject: RFR: JDK-8292276 : Add named colors from CSS Color Module Level 4
 [v28]
In-Reply-To: <n0Vl6s80AGeL92AZFcfTpUz6iy9ZtMLMTuJJvQJqJKU=.d3b23d43-275b-46b9-b27d-960edcc08df0@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <o41NUAxBjYSNOLRElD-HMRl1ZyWeAxuNnpbll_zwdx0=.fd30c3f9-3ee8-4f84-b6fe-538aaf4870bb@github.com>
 <n0Vl6s80AGeL92AZFcfTpUz6iy9ZtMLMTuJJvQJqJKU=.d3b23d43-275b-46b9-b27d-960edcc08df0@github.com>
Message-ID: <lFcvO-OvWuaBFCijXOM2_h4oEe3BnWrx1-c8CsGWCsM=.abd67e62-dde2-408b-a8a2-8c57df3e462d@github.com>

On Mon, 27 Feb 2023 20:47:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delete configure
>>   
>>   Delete configure from the pull request.
>
> src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java line 1025:
> 
>> 1023:      * and rgb or rgba HTML3.2 strings.
>> 1024:      * Otherwise, it will return null.
>> 1025:      * This method is case-insensitive.
> 
> Suggestion:
> 
>      * Note: This will only convert strings which use any of the following:
>      * <ul>
>      *   <li><a href="https://www.w3.org/TR/css-color-4/#named-colors">named colors</a>,
>      *   <li>hex color notation starting with {@code #} followed by 3, 4, 6, or 8 hexadecimal digits,
>      *   <li>`rgb()` and `rgba()` functions
>      * </ul>
>      * as specified by the <a href="https://www.w3.org/TR/css-color-4/">CSS Color Module Level 4</a>.
>      * Otherwise, it will return null.
>      * <p>
>      * This method is case-insensitive.

The _hex color notation_ and _`rgb()` and `rgba()` functions_ should link to their specifications:  
https://www.w3.org/TR/css-color-4/#hex-notation  
https://www.w3.org/TR/css-color-4/#rgb-functions  
correspondingly.

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

PR: https://git.openjdk.org/jdk/pull/9825


From aivanov at openjdk.org  Tue Feb 28 16:02:47 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 16:02:47 GMT
Subject: RFR: JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color [v13]
In-Reply-To: <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
References: <LqSjYOmTcY5K9_qGqWzzBZOnOr1yq2IigFXDQ82HoQw=.0f0f3b31-10db-4ac8-8bdd-183ef3116827@github.com>
 <PWklXjN4SgzEKf38KcjqRfp5nH6dY4YV9vBBl9sNfYk=.892cd46c-a7d6-40ef-8688-d4b80f97c86f@github.com>
Message-ID: <QkfdMu_83bZZ2NooqAmfc0KwI2hBrvdRLcLBj7fbJuU=.b45f8725-d943-4600-8ff3-c08097caa2bc@github.com>

On Sun, 5 Feb 2023 09:55:27 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8293776)
>> 
>> This is tracked in JBS as 
>> - [JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://bugs.openjdk.java.net/browse/JDK-8293776)
>> 
>> Adds the 4 and 8 digits color hex notations to CSS.java, as described in :
>> CSS Color Module Level 4
>> W3C Candidate Recommendation Snapshot, 5 July 2022
>> [6.2 The RGB Hexadecimal Notations: `#RRGGBB`](https://www.w3.org/TR/css-color-4/#hex-notation)
>> 
>> Designed from : [ScientificWare JDK-8293776 : Adds CSS 4 and 8 digits hex coded Color](https://github.com/scientificware/jdk/issues/13)
>
> ScientificWare has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.
>  - Updates copyright date.
>    
>    Updates copyright date to 2023.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1382:

> 1380:             value = dv | value << 4;
> 1381:         }
> 1382:         return new Color(value, true);

I wonder if it can be written in a clearer way. It looks cool yet not straightforward at all, so it requires explaining what's going on.

I guess a previous versions was clearer. However, I grasped how it works.

I would rather avoid assigning values inside the if-condition and extract the assignments into separate line.

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

PR: https://git.openjdk.org/jdk/pull/10317


From erikj at openjdk.org  Tue Feb 28 16:39:44 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 28 Feb 2023 16:39:44 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
Message-ID: <t1j1uipy8QKtVfBRpzf8xk0u1jlOcVFCq6oAt231ih0=.814475bb-70cb-4cf0-b869-21eb36f715e1@github.com>

On Tue, 28 Feb 2023 14:17:11 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by erikj (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12772


From aivanov at openjdk.org  Tue Feb 28 16:49:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 16:49:53 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
Message-ID: <y8pmcfwxfKBgkJXKjmAoivg4VtAxwieeeNcsV-elHew=.1638bbef-3dd0-44e7-88ae-252cf0cf153e@github.com>

On Tue, 28 Feb 2023 14:17:11 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Changes requested by aivanov (Reviewer).

doc/testing.md line 668:

> 666: Additional information about Client UI tests configuration for various operating
> 667: systems can be obtained at [Automated client GUI testing system set up
> 668: requirements] (https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)

Suggestion:

requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)


Because of the space, the link didn't get converted as expected, the HTML output contains `[]` followed by the link in `()`.

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

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 17:03:01 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 17:03:01 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>

> Added the section devoted to client UI test which use Robot API

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

  Fix link

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12772/files
  - new: https://git.openjdk.org/jdk/pull/12772/files/1ce9b932..1a3e0419

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12772&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12772/head:pull/12772

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 17:03:05 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 17:03:05 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v3]
In-Reply-To: <y8pmcfwxfKBgkJXKjmAoivg4VtAxwieeeNcsV-elHew=.1638bbef-3dd0-44e7-88ae-252cf0cf153e@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <2vbDSu-O1N0eIwgodkn8dgBpgXIzxQzw8TF5ffwJptg=.5b69e47a-01e3-4be3-820f-e8534794d703@github.com>
 <y8pmcfwxfKBgkJXKjmAoivg4VtAxwieeeNcsV-elHew=.1638bbef-3dd0-44e7-88ae-252cf0cf153e@github.com>
Message-ID: <b23sQjrPOLKNspjPFrb6Tpw0gAXU63_fDuvG3ErVK4U=.3d0dcb23-ab7b-4ddb-bbf2-c363feb06d81@github.com>

On Tue, 28 Feb 2023 16:45:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo
>
> doc/testing.md line 668:
> 
>> 666: Additional information about Client UI tests configuration for various operating
>> 667: systems can be obtained at [Automated client GUI testing system set up
>> 668: requirements] (https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)
> 
> Suggestion:
> 
> requirements](https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements)
> 
> 
> Because of the space, the link didn't get converted as expected, the HTML output contains `[]` followed by the link in `()`.

Done

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

PR: https://git.openjdk.org/jdk/pull/12772


From aivanov at openjdk.org  Tue Feb 28 17:17:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 28 Feb 2023 17:17:13 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
Message-ID: <mA7FDtKTUu5_LBCwvN-TmgUEQpdpmx34mEkD0HfyPV8=.dd0a3fbf-6659-4184-9c1b-c76ee098a318@github.com>

On Tue, 28 Feb 2023 17:03:01 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link

Marked as reviewed by aivanov (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12772


From alexsch at openjdk.org  Tue Feb 28 18:20:50 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 28 Feb 2023 18:20:50 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v7]
In-Reply-To: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
Message-ID: <Q9um8ABJkgPKQJQrYBL34ufOPhRIrEwPvHRpLBCwJLQ=.91bc70cd-6502-43af-bc06-2b3eb721a20e@github.com>

> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
> 
> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
> 
> Four rectangles are printed:
> 1. size 300x100, portrait orientation
> 2. size 300x100, landscape orientation
> 3. size 100x300, portrait orientation
> 4. size 100x300, landscape orientation
> 
> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
> 
> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
> 
> The Cocoa code that shows NSPrintInfo behavior:
> 
> #import <Cocoa/Cocoa.h>
> 
> int main()
> {
>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>     NSApp = [NSApplication sharedApplication];
> 
>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>     #define NS_PORTRAIT NSPaperOrientationPortrait
>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>     #else // code for SDK 10.8 or older
>     #define NS_PORTRAIT NSPortraitOrientation
>     #define NS_LANDSCAPE NSLandscapeOrientation
>     #endif
> 
>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
> 
>     printf("create default print info\n");
>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>     NSSize size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("call setUpPrintOperationDefaultValues\n");
>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     double w = 300.0;
>     double h = 100.0;
>     printf("set size: [%f, %f]\n", w, h);
>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     printf("Set NS_PORTRAIT orientation\n");
>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>     size = [defaultPrintInfo paperSize];
>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
> 
>     [NSApp run];
> 
>     [NSApp release];
>     [pool release];
>     return(EXIT_SUCCESS);
> } 
> 
> 
> On macOS Mojave 10.14.5 it prints:
> 
> 
> NS_PORTRAIT: 0
> NS_LANDSCAPE: 1
> create default print info
> orientation: 0, paper size: [612.000000, 792.000000]
> call setUpPrintOperationDefaultValues
> orientation: 0, paper size: [612.000000, 792.000000]
> set size: [300.000000, 100.000000]
> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
> Set NS_PORTRAIT orientation
> orientation: 0, paper size: [100.000000, 300.000000] // size flip
> ``` 
> 
> There are four possible cases for printing a rectangle with different size and orientation:
> 1. Input: paper size: (w > h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>   Note: width and height are swapped
> 2. Input: paper size: (w > h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
> 3. Input: paper size: (w < h), orientation portrait
>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
> 4. Input: paper size: (w < h), orientation landscape
>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>   Note: width and height are swapped
> 
> Only for cases 1 and 4 the final width and height are swapped.
> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
> 
> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
> Setting requested size leads that subsequent orientation flips width and height.
> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
> 
> Printed rectangles before and after the fix:
> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
> 
> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)

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

  Update check criteria in test instructions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10808/files
  - new: https://git.openjdk.org/jdk/pull/10808/files/7f536e13..1f8200c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10808&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/10808


From alexsch at openjdk.org  Tue Feb 28 18:26:11 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 28 Feb 2023 18:26:11 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v7]
In-Reply-To: <Q9um8ABJkgPKQJQrYBL34ufOPhRIrEwPvHRpLBCwJLQ=.91bc70cd-6502-43af-bc06-2b3eb721a20e@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <Q9um8ABJkgPKQJQrYBL34ufOPhRIrEwPvHRpLBCwJLQ=.91bc70cd-6502-43af-bc06-2b3eb721a20e@github.com>
Message-ID: <PkRbT8JSzW6dS1BzAvivBT3hhtjb4BlxXeMOULr8E-c=.5d6b6d07-4962-4da9-81ce-27636548d1f6@github.com>

On Tue, 28 Feb 2023 18:20:50 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
>> 
>> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
>> 
>> Four rectangles are printed:
>> 1. size 300x100, portrait orientation
>> 2. size 300x100, landscape orientation
>> 3. size 100x300, portrait orientation
>> 4. size 100x300, landscape orientation
>> 
>> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
>> 
>> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
>> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
>> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
>> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
>> 
>> The Cocoa code that shows NSPrintInfo behavior:
>> 
>> #import <Cocoa/Cocoa.h>
>> 
>> int main()
>> {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSApp = [NSApplication sharedApplication];
>> 
>>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>>     #define NS_PORTRAIT NSPaperOrientationPortrait
>>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>>     #else // code for SDK 10.8 or older
>>     #define NS_PORTRAIT NSPortraitOrientation
>>     #define NS_LANDSCAPE NSLandscapeOrientation
>>     #endif
>> 
>>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
>> 
>>     printf("create default print info\n");
>>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>>     NSSize size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("call setUpPrintOperationDefaultValues\n");
>>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     double w = 300.0;
>>     double h = 100.0;
>>     printf("set size: [%f, %f]\n", w, h);
>>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("Set NS_PORTRAIT orientation\n");
>>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     [NSApp run];
>> 
>>     [NSApp release];
>>     [pool release];
>>     return(EXIT_SUCCESS);
>> } 
>> 
>> 
>> On macOS Mojave 10.14.5 it prints:
>> 
>> 
>> NS_PORTRAIT: 0
>> NS_LANDSCAPE: 1
>> create default print info
>> orientation: 0, paper size: [612.000000, 792.000000]
>> call setUpPrintOperationDefaultValues
>> orientation: 0, paper size: [612.000000, 792.000000]
>> set size: [300.000000, 100.000000]
>> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
>> Set NS_PORTRAIT orientation
>> orientation: 0, paper size: [100.000000, 300.000000] // size flip
>> ``` 
>> 
>> There are four possible cases for printing a rectangle with different size and orientation:
>> 1. Input: paper size: (w > h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>>   Note: width and height are swapped
>> 2. Input: paper size: (w > h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
>> 3. Input: paper size: (w < h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
>> 4. Input: paper size: (w < h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>>   Note: width and height are swapped
>> 
>> Only for cases 1 and 4 the final width and height are swapped.
>> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
>> 
>> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
>> Setting requested size leads that subsequent orientation flips width and height.
>> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
>> 
>> Printed rectangles before and after the fix:
>> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
>> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
>> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
>> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
>> 
>> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update check criteria in test instructions

The test instruction improvements are added to the test.

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

PR: https://git.openjdk.org/jdk/pull/10808


From prr at openjdk.org  Tue Feb 28 19:12:05 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 19:12:05 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
Message-ID: <c-2eA6D-WcIGwnvngrl2QeZh4UVmzgTTQM-eidAPjsc=.a9b587e4-507e-430b-bb53-3817cb76380f@github.com>

On Tue, 28 Feb 2023 17:03:01 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/12772


From serb at openjdk.org  Tue Feb 28 19:12:06 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Feb 2023 19:12:06 GMT
Subject: RFR: 8303130: Document required Accessibility permissions on macOS
 [v4]
In-Reply-To: <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
 <wniGLBiEjbpaxwaIQ4E3hrcrRBflEFLO38assVDNYdc=.07d04421-8f00-45ee-b7ec-a0281a17d22f@github.com>
Message-ID: <N52UOlQmd4hVNtr3s76fk1ff1gf3s9GfIFp0p88VFQc=.b57ac0bf-a883-4f35-a6df-49cb4bb0540b@github.com>

On Tue, 28 Feb 2023 17:03:01 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

>> Added the section devoted to client UI test which use Robot API
>
> Dmitry Markov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link

Thank you for this doc update.

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

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12772


From dmarkov at openjdk.org  Tue Feb 28 19:54:28 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Tue, 28 Feb 2023 19:54:28 GMT
Subject: Integrated: 8303130: Document required Accessibility permissions on
 macOS
In-Reply-To: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
References: <r8RJEsMSnL-8llbwMq6K67Ni0juD6dF_X7lMdK3n4S8=.041e0628-cad0-4953-bd81-4895fcd57532@github.com>
Message-ID: <Lvpsdv96WuN6bWghsGkNEZj-ZF975F987R3O1ZivDAU=.58dbe662-b2fa-406b-a07a-883cae5e61b5@github.com>

On Mon, 27 Feb 2023 15:54:28 GMT, Dmitry Markov <dmarkov at openjdk.org> wrote:

> Added the section devoted to client UI test which use Robot API

This pull request has now been integrated.

Changeset: a10d5ac6
Author:    Dmitry Markov <dmarkov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a10d5ac61be3d074937f629959c7aeb694147203
Stats:     60 lines in 2 files changed: 54 ins; 0 del; 6 mod

8303130: Document required Accessibility permissions on macOS

Reviewed-by: erikj, aivanov, prr, serb

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

PR: https://git.openjdk.org/jdk/pull/12772


From duke at openjdk.org  Tue Feb 28 20:03:43 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 28 Feb 2023 20:03:43 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v5]
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <8Ai_u7WglVIr8YrL3vF4pUUlJoDa3Xjn-PwMpto0__I=.c2394a7f-c201-4cba-8c3b-8ce39d8e3a5f@github.com>

> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
> 
> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
> 
> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
> 
> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
> 
> See also #6603, where this issue was discovered.

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

  Revert "Make default fonts FontUIResources"
  
  This reverts commit 1cc422224331440317150f80cf567338376f95df.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10565/files
  - new: https://git.openjdk.org/jdk/pull/10565/files/1cc42222..7dfcaf25

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=03-04

  Stats: 10 lines in 4 files changed: 1 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10565/head:pull/10565

PR: https://git.openjdk.org/jdk/pull/10565


From duke at openjdk.org  Tue Feb 28 20:09:04 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 28 Feb 2023 20:09:04 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v6]
In-Reply-To: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
Message-ID: <ST1oWUx7t2KlAaXgg1a-7w4kmoER8RL1kTfGhHEynT4=.f7d3b510-eabc-4862-ab90-c1d3fe3c9a71@github.com>

> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
> 
> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
> 
> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
> 
> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
> 
> See also #6603, where this issue was discovered.

SWinxy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into 8278620
   
   # Conflicts:
   #	src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java
 - Revert "Make default fonts FontUIResources"
   
   This reverts commit 1cc422224331440317150f80cf567338376f95df.
 - Make default fonts FontUIResources
 - Minor cleanup on StalePreferredSize
 - BasicPanelUI uninstalling font causes cascading problems
 - Merge branch 'master' into 8278620
 - Sync with CSR
   
   Only difference is that I added an Oxford comma
 - Accidental imports added
 - 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled
   
   Many installDefaults methods set the font, foreground, and background on objects but their inverse methods uninstallDefaults do not remove them. I've added an inverse method to remove the colors and font to call for the uninstallDefaults methods that install defaults.
   
   AquaButtonUI can call its super since it would otherwise be repeated code. BasicComboBoxUI (weirdly) installs the properties again when it should be uninstalling them, so I changed.
   
   I noticed that, in a few subclasses, only one of calls to the super of installDefaults and uninstallDefaults are made. That is, an overridden installDefaults may call its super while the overridden uninstallDefaults does not call its super (or vise versa). These classes are: AquaTabbedPaneUI, SynthMenuItemUI, SynthSplitPaneUI, and XTextAreaPeer.

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

Changes: https://git.openjdk.org/jdk/pull/10565/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10565&range=05
  Stats: 173 lines in 28 files changed: 87 ins; 48 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/10565.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10565/head:pull/10565

PR: https://git.openjdk.org/jdk/pull/10565


From prr at openjdk.org  Tue Feb 28 20:48:08 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 20:48:08 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v2]
In-Reply-To: <9oErSGZO2hcusvCEEV2eJTgmev_v-5OJclGdyyLwPJg=.2f44899a-2a76-42c1-bde7-b180c5b991ef@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <bZ-5w5PhkoBOabyssVSgIqIaltz5g2UgFXWfy0AKXt8=.2bcacff6-2300-4dba-9b19-f3519e82e412@github.com>
 <Ndpon4VisLCPStqWMubR1dQLXNlhXyy0AS1Jclc2EmI=.e9c54c7c-7016-4daf-acac-eed9c65cc4d3@github.com>
 <ZKhjLFnOiE_YK5D0W63vlWS8pNXaC_vAK7uMsb-XX3w=.717990e5-056e-4987-a5d0-d71e1db6456c@github.com>
 <9oErSGZO2hcusvCEEV2eJTgmev_v-5OJclGdyyLwPJg=.2f44899a-2a76-42c1-bde7-b180c5b991ef@github.com>
Message-ID: <e_AXIx4RQMxU3gMqz6vj1BE5J7RMC5LdyuY2QiHR6KE=.e8e30fb8-f9e1-47e9-abda-d05f93f52533@github.com>

On Tue, 28 Feb 2023 13:57:21 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Thanks @prrace for your inputs.
>> I dont think -fPIC is implied by -fpic. @erikj79  please clarify.
>> 
>> Difference between -fpic and -fPIC:
>> 1) With -fPIC we have unlimited storage capacity for global offset table and with -fpic on some platforms we have limitation on this size. For aarch64 it is 28k, but in case of x86 size of GOT is unlimited irrespective of -fPIC or -fpic. This is already captured.
>> 2) Also it looks like if we use -fpic option instead of -fPIC we may generate smaller/faster code as mentioned at http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html. Looks like in our case, 28k GOT size suffices and we are able to create smaller/faster code for libawt in case of aarch64. This inturn looks to be related to usage of -msmall-data or -mlarge-data flags. -fpic implies -msmall-data and -fPIC implies -mlarge-data while generating code for shared libraries. -msmall-data also talks about data being nearer and easily accessible compared to  -mlarge-data(https://man7.org/linux/man-pages/man1/gcc.1.html)
>> 
>> Also i can make this change specific to aarch64 since we are seeing its effect only on aarch64.
>
> I think you have read more about the differences between -fpic and -fPIC than I have, so nothing I can add here.
> 
> Making this option only on aarch64 seems like a reasonable idea if that's where we see the effect.

> I dont think -fPIC is implied by -fpic. @erikj79 please clarify.

That isn't what I said.
I said they they do very similar things, based on the references I read
with just a specific difference is that lower case "fpic" can be limited in size.

which is why I  wrote
>  So far as I can tell the -fpic are using just limits the size of the global offset table that -fPIC will generate.

My comment
> Since we had an unlimited offset table before, then -fpic won't change anything.

I was trying to point out that if your eval + fix is explained by saying we no longer
have "-fpic" then that's wrong. We never had -fpic.
We didn't change compiler options, but clearly performance changed


The man page you just linked does explain how the mechanism -fpic uses
which limits size could result in better performance

" When generating code for shared libraries, -fpic implies
           -msmall-data and -fPIC implies -mlarge-data."

"When -msmall-data is used,
           objects 8 bytes long or smaller are placed in a small data
           area (the ".sdata" and ".sbss" sections) and are accessed via
           16-bit relocations off of the $gp register."
 
So on some architectures it can be faster.

BUT since we were using -fPIC for a long time, I am not seeing how  you've
explained WHY we now need to explicitly use -fpic to get the performance back ?
In other words "we mysteriously lost performance, but I've found an option that helps".

So possibly, if you applied -fpic to the JDK before the regression it would get even faster ...

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

PR: https://git.openjdk.org/jdk/pull/12761


From prr at openjdk.org  Tue Feb 28 20:51:12 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 20:51:12 GMT
Subject: RFR: 8295737: macOS: Print content cut off when width > height
 with portrait orientation [v7]
In-Reply-To: <Q9um8ABJkgPKQJQrYBL34ufOPhRIrEwPvHRpLBCwJLQ=.91bc70cd-6502-43af-bc06-2b3eb721a20e@github.com>
References: <OSKa2aisTdvngZ7CgwgivgVsz2UqhoXm2w4o5AD_zYE=.d0953139-cc1d-4ef2-b97e-374162d652fd@github.com>
 <Q9um8ABJkgPKQJQrYBL34ufOPhRIrEwPvHRpLBCwJLQ=.91bc70cd-6502-43af-bc06-2b3eb721a20e@github.com>
Message-ID: <0t87RM9aIc-fpg_9lhxw4lEKuyBeXdCVBnWVJ7trVGU=.19411219-c195-4821-a132-18382edd02ee@github.com>

On Tue, 28 Feb 2023 18:20:50 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> A printed content is truncated on macOS if the content paper size width larger than height with portrait orientation or width is less than height with landscape orientation.
>> 
>> To reproduce the issue run the [CutOffImage](https://bugs.openjdk.org/secure/attachment/101145/CutOffImage.java) sample on MacOS.
>> 
>> Four rectangles are printed:
>> 1. size 300x100, portrait orientation
>> 2. size 300x100, landscape orientation
>> 3. size 100x300, portrait orientation
>> 4. size 100x300, landscape orientation
>> 
>> The first and fourth rectangles are truncated: [cut off content](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf)
>> 
>> The reason is that NSPrintInfo class does not allow to set paper size and orientation independently.
>> Setting paper size width large than height changes NSPrintInfo orientation to landscape.
>> Setting paper size width less than height changes NSPrintInfo orientation to portrait.
>> Updating NSPrintInfo orientation from landscape to portrait or from portrait to landscape swaps NSPrintInfo paper width and height.
>> 
>> The Cocoa code that shows NSPrintInfo behavior:
>> 
>> #import <Cocoa/Cocoa.h>
>> 
>> int main()
>> {
>>     NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>>     NSApp = [NSApplication sharedApplication];
>> 
>>     #ifdef __MAC_10_9 // code for SDK 10.9 or newer
>>     #define NS_PORTRAIT NSPaperOrientationPortrait
>>     #define NS_LANDSCAPE NSPaperOrientationLandscape
>>     #else // code for SDK 10.8 or older
>>     #define NS_PORTRAIT NSPortraitOrientation
>>     #define NS_LANDSCAPE NSLandscapeOrientation
>>     #endif
>> 
>>     printf("NS_PORTRAIT: %d\n", NS_PORTRAIT);
>>     printf("NS_LANDSCAPE: %d\n", NS_LANDSCAPE);
>> 
>>     printf("create default print info\n");
>>     NSPrintInfo* defaultPrintInfo = [[NSPrintInfo sharedPrintInfo] copy];
>>     NSSize size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("call setUpPrintOperationDefaultValues\n");
>>     [defaultPrintInfo setUpPrintOperationDefaultValues];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     double w = 300.0;
>>     double h = 100.0;
>>     printf("set size: [%f, %f]\n", w, h);
>>     [defaultPrintInfo setPaperSize:NSMakeSize(w, h)];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     printf("Set NS_PORTRAIT orientation\n");
>>     [defaultPrintInfo setOrientation: NS_PORTRAIT];
>>     size = [defaultPrintInfo paperSize];
>>     printf("orientation: %d, paper size: [%f, %f]\n", [defaultPrintInfo orientation], size.width, size.height);
>> 
>>     [NSApp run];
>> 
>>     [NSApp release];
>>     [pool release];
>>     return(EXIT_SUCCESS);
>> } 
>> 
>> 
>> On macOS Mojave 10.14.5 it prints:
>> 
>> 
>> NS_PORTRAIT: 0
>> NS_LANDSCAPE: 1
>> create default print info
>> orientation: 0, paper size: [612.000000, 792.000000]
>> call setUpPrintOperationDefaultValues
>> orientation: 0, paper size: [612.000000, 792.000000]
>> set size: [300.000000, 100.000000]
>> orientation: 1, paper size: [300.000000, 100.000000] // orientation flip
>> Set NS_PORTRAIT orientation
>> orientation: 0, paper size: [100.000000, 300.000000] // size flip
>> ``` 
>> 
>> There are four possible cases for printing a rectangle with different size and orientation:
>> 1. Input: paper size: (w > h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (h, w), orientation: portrait
>>   Note: width and height are swapped
>> 2. Input: paper size: (w > h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (w, h), orientation: landscape
>> 3. Input: paper size: (w < h), orientation portrait
>>   [dstPrintInfo setPaperSize: NSMakeSize(w, h)]  // size: (w, h), orientation: portrait
>>   [dstPrintInfo setOrientation: NS_PORTRAIT]     // size: (w, h), orientation: portrait
>> 4. Input: paper size: (w < h), orientation landscape
>>   [dstPrintInfo setPaperSize: NSMakeSize(h, w)]  // size: (h, w), orientation: landscape
>>   [dstPrintInfo setOrientation: NS_LANDSCAPE]  // size: (h, w), orientation: landscape
>>   Note: width and height are swapped
>> 
>> Only for cases 1 and 4 the final width and height are swapped.
>> The proposed fix enlarges height for cases 1 and 4 to not cut the printed rectangle.
>> 
>> It is not full fix which draws rectangles for cases 1 and 4 in the requested size.
>> Setting requested size leads that subsequent orientation flips width and height.
>> The fix only enlarges the truncated area in height direction. The enlarged area in width is preserved as before the fix.
>> 
>> Printed rectangles before and after the fix:
>> 1. size 300x100, portrait orientation: [before-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101157/before-fix-1.pdf),  [after-fix-1.pdf](https://bugs.openjdk.org/secure/attachment/101162/after-fix-1.pdf)
>> 2. size 300x100, landscape orientation: [before-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101156/before-fix-2.pdf),  [after-fix-2.pdf](https://bugs.openjdk.org/secure/attachment/101161/after-fix-2.pdf)
>> 3. size 100x300, portrait orientation: [before-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101155/before-fix-3.pdf),  [after-fix-3.pdf](https://bugs.openjdk.org/secure/attachment/101160/after-fix-3.pdf)
>> 4. size 100x300, landscape orientation: [before-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101154/before-fix-4.pdf),  [after-fix-4.pdf](https://bugs.openjdk.org/secure/attachment/101159/after-fix-4.pdf)
>> 
>> All four rectangles: [before-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101153/before-fix-all.pdf),  [after-fix-all.pdf](https://bugs.openjdk.org/secure/attachment/101158/after-fix-all.pdf)
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update check criteria in test instructions

Marked as reviewed by prr (Reviewer).

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

PR: https://git.openjdk.org/jdk/pull/10808


From prr at openjdk.org  Tue Feb 28 21:01:08 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 21:01:08 GMT
Subject: RFR: 8303213: Avoid AtomicReference in TextComponentPrintable [v3]
In-Reply-To: <QhHAcBulgK3Ant6S--KFqXAHsPUMDWi4gYAhq0l85aY=.f76781f8-033c-436d-9ccb-cf03ff2b308e@github.com>
References: <hACfpJKLgTfAaHYCf18nHsLY6-CmJO8w3lhtQu0Oi2g=.4d983711-25b0-4f7e-bc50-b8d2c97da81d@github.com>
 <QhHAcBulgK3Ant6S--KFqXAHsPUMDWi4gYAhq0l85aY=.f76781f8-033c-436d-9ccb-cf03ff2b308e@github.com>
Message-ID: <My5iyBVUKU_cCYwL10gA-XCQzGr_wBUIyO20eP7Ve1w=.69ce333e-9e47-4d5e-acef-a12d6a170625@github.com>

On Mon, 27 Feb 2023 20:48:22 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> If CompareAndSwap is not used, then AtomicReference could be replaced with volatile. It simplified code a bit.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303213: Avoid AtomicReference in TextComponentPrintable
>   
>   expand star import

How was this change tested ? 
Did you run any Swing printing tests that exercise this code ?
If you did not find such a test, you can write one.

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

PR: https://git.openjdk.org/jdk/pull/12018


From duke at openjdk.org  Tue Feb 28 21:06:13 2023
From: duke at openjdk.org (SWinxy)
Date: Tue, 28 Feb 2023 21:06:13 GMT
Subject: RFR: 8278620: properties installed by javax.swing.LookAndFeel
 installColors and installColorsAndFont are not uninstalled [v6]
In-Reply-To: <ST1oWUx7t2KlAaXgg1a-7w4kmoER8RL1kTfGhHEynT4=.f7d3b510-eabc-4862-ab90-c1d3fe3c9a71@github.com>
References: <QPkrdy50Y7WRAm-NkWnaOvg7DamorZMJxzAuMusDHWc=.0b518789-72b7-4c69-a776-3c50e9263d74@github.com>
 <ST1oWUx7t2KlAaXgg1a-7w4kmoER8RL1kTfGhHEynT4=.f7d3b510-eabc-4862-ab90-c1d3fe3c9a71@github.com>
Message-ID: <kVGHdRo1-RZO6TjONwZ58lDg_bI2UzDGl-qgYCFVvSU=.d94c2d27-c3c7-4176-9256-1e544cadb3b9@github.com>

On Tue, 28 Feb 2023 20:09:04 GMT, SWinxy <duke at openjdk.org> wrote:

>> Many `installDefaults` methods set the font, foreground, and background on objects but their inverse methods `uninstallDefaults` do not remove them. I've added an inverse method to remove the colors and font to call for the `uninstallDefaults` methods that install defaults.
>> 
>> `AquaButtonUI` can call its super since it would otherwise be repeated code. `BasicComboBoxUI` (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>> 
>> I noticed that, in a few subclasses, only one of calls to the super of `installDefaults` and `uninstallDefaults` are made. That is, an overridden `installDefaults` may call its super while the overridden `uninstallDefaults` does not call its super (or vise versa). These classes are: `AquaTabbedPaneUI`, `SynthMenuItemUI`, `SynthSplitPaneUI`, and `XTextAreaPeer`.
>> 
>> Sorry I couldn't write a test; I wasn't sure how I should have accessed the protected variable aside from creating extending classes for each class that changed.
>> 
>> See also #6603, where this issue was discovered.
>
> SWinxy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Merge branch 'master' into 8278620
>    
>    # Conflicts:
>    #	src/java.desktop/macosx/classes/com/apple/laf/AquaButtonUI.java
>  - Revert "Make default fonts FontUIResources"
>    
>    This reverts commit 1cc422224331440317150f80cf567338376f95df.
>  - Make default fonts FontUIResources
>  - Minor cleanup on StalePreferredSize
>  - BasicPanelUI uninstalling font causes cascading problems
>  - Merge branch 'master' into 8278620
>  - Sync with CSR
>    
>    Only difference is that I added an Oxford comma
>  - Accidental imports added
>  - 8278620: properties installed by javax.swing.LookAndFeel installColors and installColorsAndFont are not uninstalled
>    
>    Many installDefaults methods set the font, foreground, and background on objects but their inverse methods uninstallDefaults do not remove them. I've added an inverse method to remove the colors and font to call for the uninstallDefaults methods that install defaults.
>    
>    AquaButtonUI can call its super since it would otherwise be repeated code. BasicComboBoxUI (weirdly) installs the properties again when it should be uninstalling them, so I changed.
>    
>    I noticed that, in a few subclasses, only one of calls to the super of installDefaults and uninstallDefaults are made. That is, an overridden installDefaults may call its super while the overridden uninstallDefaults does not call its super (or vise versa). These classes are: AquaTabbedPaneUI, SynthMenuItemUI, SynthSplitPaneUI, and XTextAreaPeer.

Apologies for the delay. I wrongly assumed that making the fonts FontUIResources would fix it. I only ran the tests on macOS, which is absolutely my fault. I'm not testing enough before submitting PRs. ?

> > Maybe we are going about this all wrong ?
> > Maybe uninstall isn't needed ?
> > What are the rules (set by Swing?) for what a L&F should do when installing a UI ? If it is "if there is a FontUIResource, then feel free to replace it with yours" then may be everything in this PR (at least about fonts) is un-needed ?
> 
> With where the testing led us, I'm inclined to think that the omission of nullifying the font in `uninstallUI` wasn't accidental but rather a deliberate decision.

I don't *think* it was deliberate. Probably this same issue was ran into back then, and the easiest thing to do was to not remove the font.

> The description of JDK-8278620 states BasicListUI correctly uninstalls all its properties, including the font. Why is it not affected by the problem we're seeing here where the font gets reset to a non-ResourceUI font from the heavyweight peer of the frame?

And I'm also not sure why! I'll do some more investigating. Thanks for the writeup, Alexey.

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

PR: https://git.openjdk.org/jdk/pull/10565


From prr at openjdk.org  Tue Feb 28 23:16:03 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Feb 2023 23:16:03 GMT
Subject: RFR: 8302495: update for deprecated sprintf for java.desktop
In-Reply-To: <OLGmS8aYffBUxJiCTzPUI_1P3Xk3_QYMyOk9WbXs-ZE=.aa49860b-0583-4f78-a50c-ef16a5780775@github.com>
References: <JYJw1uv3LBUZ_4fAsYcg_EVC0D_biKkhQcrWPWABsBQ=.91aeffce-37e2-4f4a-9e6f-ed8b8c5bdcc6@github.com>
 <MGbT7kXybrpTCiM4cFtciem4W6zPHumw0V8G4B9nsPM=.be07ee3b-5582-432b-afd4-627fda3480ea@github.com>
 <OLGmS8aYffBUxJiCTzPUI_1P3Xk3_QYMyOk9WbXs-ZE=.aa49860b-0583-4f78-a50c-ef16a5780775@github.com>
Message-ID: <ald6a7wUUU1EZUuDYiyl67NoP30YiIah9vOuc_hGZv8=.aae67215-3ca9-4652-980c-1de19a502cc8@github.com>

On Wed, 22 Feb 2023 19:42:12 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> > This is a fairly extensive set of changes so I'll contact you off-line to make sure you have done adequate testing.
> 
> Thank you for your looking into the issue.
> 
> I'm new to java.desktop. Exception the regression tests, what else should I run to make sure everything is OK? Can someone in Oracle help me run Mach5 jobs for tier1, tier2 and jdk_desktop?
> 
> > Also the changes in freetype must be reverted. This is a 3rd party library.
> 
> The update in freetype was reverted.

Sorry, I got sidetracked away from this, so let me submit a test job to our internal CI system which should cover this.
Note that "tier1 and tier2" are utterly irrelevant to any code in the java.desktop module.  A complete waste of time running them.
Same for github actions.

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

PR: https://git.openjdk.org/jdk/pull/12565


From serb at openjdk.org  Tue Feb 28 23:58:04 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 28 Feb 2023 23:58:04 GMT
Subject: RFR: 8301869: Regression ~14% in J2dBench-bimg_misc-* in 21-b5
 only on linux-aarch64 [v3]
In-Reply-To: <iQV2krpbZWIo9qMv7o9Hpa4BokiURJM2XX5OBzxBex8=.cd5fa1bf-5bdd-4d40-a636-a9e0b16a3837@github.com>
References: <dTAYCLRo_q4AU-MsiMLGMQcsMDRcWDg1zleYvXBalTQ=.8f15b134-8d32-4e2a-a92e-839ef488604e@github.com>
 <iQV2krpbZWIo9qMv7o9Hpa4BokiURJM2XX5OBzxBex8=.cd5fa1bf-5bdd-4d40-a636-a9e0b16a3837@github.com>
Message-ID: <T1p4rkxace2Uaz5Wvomf0AtmF72jECF3VSvrqaCIvTU=.121b6add-b62f-4cb5-89cd-8f5bb820752b@github.com>

On Tue, 28 Feb 2023 06:55:36 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Under https://bugs.openjdk.org/browse/JDK-8264846 we moved to -O3 level of gcc optimizations from -O1 level for libawt build. This improved our J2DBench performance numbers in some options considerably.
>> 
>> Recent changes done under https://bugs.openjdk.org/browse/JDK-8299337 causes difference in generated code by gcc and this is resulting in performance regression for bimg_misc-* J2DBench options in our performance servers. Under https://bugs.openjdk.org/browse/JDK-8299337 we have just removed unused variables and it is a cleanup task.
>> 
>> We can force gcc to generate position independent code by using -fpic option.Also i have removed -fgcse-after-reload option for gcc, because this is by default covered under -O3 level of optimization introduced under https://bugs.openjdk.org/browse/JDK-8264846.
>> 
>> With this change bimg_misc-* J2DBench option performance regression is resolved and there are no regression in other options of J2DBench or SwingMark and it is verified in our performance servers.
>
> Jayathirth D V has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Shift comment

When I mention that option in the JBS, I meant that we should take a look on how the methods in the library are "packed" since for some reason "-fpic" make some difference, probably we should use "static" more often or something like that. It is better to check what is the actual difference in the generated/packed code.

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

PR: https://git.openjdk.org/jdk/pull/12761