From tr at openjdk.org  Mon Aug  1 06:16:46 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 1 Aug 2022 06:16:46 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v5]
In-Reply-To: <AIus88g7s308GZyyZqbVihnnW_0glFFsba_sNFQkBaw=.eb76407b-017a-4d3a-9105-bd9fbc7d11f8@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <Cv5J_ReeVFyd56W9tPkXgzpzdcxYtW6SWTxZeF9HiSc=.6c8cd2eb-caa2-4339-a711-52267be76249@github.com>
 <AIus88g7s308GZyyZqbVihnnW_0glFFsba_sNFQkBaw=.eb76407b-017a-4d3a-9105-bd9fbc7d11f8@github.com>
Message-ID: <mLE0dNpAAAcZ6TZgs4UVqhb1ibeHOdd7yB1xOsFRQlY=.4547ecb1-4e98-49f0-9b99-33a36b9939b7@github.com>

On Fri, 29 Jul 2022 16:50:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix: Java doc modified and Graphics contexts created in null case
>
> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 87:
> 
>> 85:         //  directly.
>> 86:         StackWalker walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>> 87:         if ((graphics == null) && (walker.getCallerClass() != this.getClass())) {
> 
> I don't know if creating a StackWalker is expensive but I think it should be done only if graphics == null
> 
> Also the version of getInstance() being called here might throw SecurityException
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getInstance(java.lang.StackWalker.Option)
> 
> So you'll need to wrap it in a doPrivileged.

Checking only if `graphics == null `will also handle the case when user sets the `graphics` to null by passing null in the constructor, so removing StackWalker and checking only for `graphics == null` will handle both the cases whether its internal class or called from other class.

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

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


From tr at openjdk.org  Mon Aug  1 06:19:39 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 1 Aug 2022 06:19:39 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v5]
In-Reply-To: <AIus88g7s308GZyyZqbVihnnW_0glFFsba_sNFQkBaw=.eb76407b-017a-4d3a-9105-bd9fbc7d11f8@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <Cv5J_ReeVFyd56W9tPkXgzpzdcxYtW6SWTxZeF9HiSc=.6c8cd2eb-caa2-4339-a711-52267be76249@github.com>
 <AIus88g7s308GZyyZqbVihnnW_0glFFsba_sNFQkBaw=.eb76407b-017a-4d3a-9105-bd9fbc7d11f8@github.com>
Message-ID: <aAd-YjYnJ3d0mVt1ApwCvGWWUjU7Ot2mGHqjzya07FQ=.24e6f661-4f9c-4935-832c-17d0e82301e8@github.com>

On Fri, 29 Jul 2022 16:50:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix: Java doc modified and Graphics contexts created in null case
>
> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 87:
> 
>> 85:         //  directly.
>> 86:         StackWalker walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>> 87:         if ((graphics == null) && (walker.getCallerClass() != this.getClass())) {
> 
> I don't know if creating a StackWalker is expensive but I think it should be done only if graphics == null
> 
> Also the version of getInstance() being called here might throw SecurityException
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getInstance(java.lang.StackWalker.Option)
> 
> So you'll need to wrap it in a doPrivileged.

@prrace Shall I proceed by removing Stackwalker and create a graphics instance only if its `null`......?

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

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


From tr at openjdk.org  Mon Aug  1 07:20:39 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 1 Aug 2022 07:20:39 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
In-Reply-To: <Cy227uR6Q9jzZe_jiureJYILenkC5nKUQni6a0k1qdY=.aa2e0cae-0329-4376-aafc-7ec36f7b768b@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <N0aSqPyUYe6_EORrKOnWLadI2Scqz1iFq-skz-XFExQ=.abfc76cf-8b5c-41a5-98ae-633d401282e3@github.com>
 <Cy227uR6Q9jzZe_jiureJYILenkC5nKUQni6a0k1qdY=.aa2e0cae-0329-4376-aafc-7ec36f7b768b@github.com>
Message-ID: <jVeQppGmHshEXYvyHKaSjF_erihtfxNcTXPqZXgY8Cs=.e01ee66a-ee71-4ddd-b3e4-06b0ac5c29e5@github.com>

On Fri, 29 Jul 2022 18:28:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 749:
>> 
>>> 747:                             } else {
>>> 748:                                 chooser.setSelectedFile(null);
>>> 749:                             }
>> 
>> What about the case where multiselection is enabled? It likely needs updating too.
>
> Are symbolic links to files handled correctly?

In multiselection case the same issue exists where it doesn't allow user to multi select the Symbolic links. Code modification is required to handle multiselection case. And symbolic links to files are handled correctly, no issue with that.

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

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


From alanb at openjdk.org  Mon Aug  1 07:22:35 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 07:22:35 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>

On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
> 
> The issue could be reproduced by zero.

For the XMLDecoder tests then I think the issue is that it's using the 1-arg Class.forName rather than the 3-arg Class.forName. Can you try this:


diff --git a/test/jdk/java/beans/XMLDecoder/8028054/Task.java b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
index 1d55fa8e358..add48336d16 100644
--- a/test/jdk/java/beans/XMLDecoder/8028054/Task.java
+++ b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
@@ -130,8 +130,9 @@ abstract class Task<T> implements Runnable {
                 .map(s -> s.substring(s.indexOf("java")))
                 .collect(Collectors.toList());
 
+        ClassLoader scl = ClassLoader.getSystemClassLoader();
         for (String name : fileNames) {
-            classes.add(Class.forName(name));
+            classes.add(Class.forName(name, false, scl));
             if (count == classes.size()) {
                 break;
             }

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

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


From tr at openjdk.org  Mon Aug  1 10:27:03 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 1 Aug 2022 10:27:03 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v2]
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <YTO50XW2bmeme1SzMkQCvVciS-wELjEc5CDWATtiBwE=.c855c1fe-299c-44d7-9551-5aac3a861a60@github.com>

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

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

 - Fix : Updated to handle multiSelection case
 - Manual Test Indicator Added in JTREG tag

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9597/files
  - new: https://git.openjdk.org/jdk/pull/9597/files/82612a0a..0406d504

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

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

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


From tr at openjdk.org  Mon Aug  1 10:44:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 1 Aug 2022 10:44:54 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v6]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <NyixviBjJKgQJTKTkFOjLj-PQ4gTiYr3AddXPqNvha8=.353861a1-9b88-4ee2-a055-31fb68410dfd@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

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

 - Updations on removing StackWalker for graphics instance and test updations based on review
 - Minor <p> update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/22bc13a4..d9d62c86

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

  Stats: 31 lines in 2 files changed: 1 ins; 26 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9673.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9673/head:pull/9673

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


From duke at openjdk.org  Mon Aug  1 11:01:58 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Mon, 1 Aug 2022 11:01:58 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v12]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <-jB87It9Ls537Um6y9hcTwz5OE-WVa-zgsbfCL7GG38=.6cc5e3f3-602f-4fdc-8196-df506c9c0b3a@github.com>

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

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

  Fix rotated text metrics

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/07150fbd..83d5da54

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

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 psadhukhan at openjdk.org  Mon Aug  1 11:12:43 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Aug 2022 11:12:43 GMT
Subject: Integrated: 6463708: DefaultButtonModel.setMnemonic generates
 ChangeEvent for no change
In-Reply-To: <ojo79_vns_6C0Wm6Cy67i-gG4lYrJ4yKLQMaLP753vc=.2f46cacd-8ca5-4749-8ba5-e865eb01ffd7@github.com>
References: <ojo79_vns_6C0Wm6Cy67i-gG4lYrJ4yKLQMaLP753vc=.2f46cacd-8ca5-4749-8ba5-e865eb01ffd7@github.com>
Message-ID: <MtqAMAEY-6CtEbE4dfb_KhzgWAMRrh2julkQWAGZZF4=.1a91b9b7-6698-42a7-9324-01460b01d5bd@github.com>

On Mon, 18 Jul 2022 08:42:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> For a DefaultButtonModel, setMnemonic() generates a ChangeEvent even if the new value is the same as the old value (that is, even if nothing has changed). 
> Fix is to fire StateChange event only if the value has changed. 
> 
> This is consistent with other places like 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/colorchooser/DefaultColorSelectionModel.java#L103
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultSingleSelectionModel.java#L79
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/DefaultBoundedRangeModel.java#L309

This pull request has now been integrated.

Changeset: f5d1b5bd
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5d1b5bda27c798347ae278cbf69725ed4be895c
Stats:     64 lines in 2 files changed: 62 ins; 0 del; 2 mod

6463708: DefaultButtonModel.setMnemonic generates ChangeEvent for no change

Reviewed-by: azvegint, prr

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

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


From aoqi at openjdk.org  Mon Aug  1 12:02:02 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 12:02:02 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" [v2]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <Us2WLe6tvDTtiBgYBElsWmC_3OPgUAkagCIu45xbf3M=.c50985e0-e47b-49c2-b1e9-4ebd90963d52@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
> 
> The issue could be reproduced by zero.

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

  XMLDecoder update
  
  Co-authored-by: Alan Bateman <alanb at openjdk.org>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/c16a0b87..623e3723

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

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

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


From aoqi at openjdk.org  Mon Aug  1 12:04:41 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 12:04:41 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
In-Reply-To: <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
Message-ID: <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>

On Mon, 1 Aug 2022 07:18:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
>> 
>> The issue could be reproduced by zero.
>
> For the XMLDecoder tests then I think the issue is that it's using the 1-arg Class.forName rather than the 3-arg Class.forName. Can you try this:
> 
> 
> diff --git a/test/jdk/java/beans/XMLDecoder/8028054/Task.java b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
> index 1d55fa8e358..add48336d16 100644
> --- a/test/jdk/java/beans/XMLDecoder/8028054/Task.java
> +++ b/test/jdk/java/beans/XMLDecoder/8028054/Task.java
> @@ -130,8 +130,9 @@ abstract class Task<T> implements Runnable {
>                  .map(s -> s.substring(s.indexOf("java")))
>                  .collect(Collectors.toList());
>  
> +        ClassLoader scl = ClassLoader.getSystemClassLoader();
>          for (String name : fileNames) {
> -            classes.add(Class.forName(name));
> +            classes.add(Class.forName(name, false, scl));
>              if (count == classes.size()) {
>                  break;
>              }

Hi @AlanBateman , your method works. It is a much better way. Thank you very much!

Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two?

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

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


From duke at openjdk.org  Mon Aug  1 12:47:44 2022
From: duke at openjdk.org (Joe)
Date: Mon, 1 Aug 2022 12:47:44 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
Message-ID: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>

8289562: Change bugs.java.com and bugreport.java.com URL's to https

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

Commit messages:
 - Merge branch 'openjdk:master' into master
 - changed the hrl from http to https JDK-8289562

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

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


From mkartashev at openjdk.org  Mon Aug  1 14:23:56 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 1 Aug 2022 14:23:56 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
Message-ID: <x0mBtfwIQfOr4RCYSW-N6triak3GmnYrKW4cnV-_cts=.45090aa9-4573-41d3-9e8b-9834e29d52d3@github.com>

On Mon, 4 Jul 2022 09:31:05 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
> 
> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
> 
> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.

(as a side note: many thanks for such an in-depth review).

> What I can imagine is that the storage change may not yet be visible to the Disposer thread, or becomes visible as it is in the process of clearing the deferred records.

In the specific macOS case I'm sure that's the right explanation for the crash. But `Disposer` is a public class that is being widely used throughout JDK and as far as I can see nothing in its contract prevents it from being used in a way I described and illustrated with the second test. Perhaps I was unnecessarily generic in my description.

> It is useless to test this in headless mode since there is no RenderQueue .. and so this whole scenario never happens I think it sufficient to make the EXISTING test headful .. the harness will report a failure automatically if there's a crash

Let me drop that test and make the existing one headful.

> Both new tests don't seem needed and the 2nd one doesn't seem to be testing the issue at all .. as I wrote above we do not run these concurrently and your test does nothing to block the disposer thread.

On the issue of the second test, I still believe it is useful:
- it demonstrates a legitimate problem with `Disposer`, albeit admittedly a different one than reported in the bug,
- it shows the problem more clearly as the problematic usage pattern of `Disposer` is contained in the test itself and not buried in JDK code,
- it crashes more reliably,
- it shows that the problem (at least potentially) exists on Linux also,
- it does not have to be marked headful.

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

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


From mkartashev at openjdk.org  Mon Aug  1 14:30:54 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Mon, 1 Aug 2022 14:30:54 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS [v2]
In-Reply-To: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
Message-ID: <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>

> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
> 
> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
> 
> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.

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

  Made DrawRotatedStringUsingRotatedFont.java headful and dropped extra test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9362/files
  - new: https://git.openjdk.org/jdk/pull/9362/files/a1c76241..eb393c6b

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

  Stats: 48 lines in 2 files changed: 1 ins; 46 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9362.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9362/head:pull/9362

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


From fmatte at openjdk.org  Mon Aug  1 14:32:47 2022
From: fmatte at openjdk.org (Fairoz Matte)
Date: Mon, 1 Aug 2022 14:32:47 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <yKAWQeCCkJiO3lvHnWLvEKVuWTt9R3JEkxgnIiEWW8E=.e48cfdf8-8fa0-47a1-bfb3-874bcffaadd7@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

It is a trivial change and looks good to me (I am not a reviewer).

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

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


From alanb at openjdk.org  Mon Aug  1 15:56:48 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 15:56:48 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations"
In-Reply-To: <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
 <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
Message-ID: <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>

On Mon, 1 Aug 2022 12:02:19 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two?

I think it would be better to split them.

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

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


From aoqi at openjdk.org  Mon Aug  1 16:25:14 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 16:25:14 GMT
Subject: RFR: 8291508: Fix some tests with "requires vm.continuations" [v3]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <RVvuKD6GmNvSf0gvQITk2OWA2M_y7UG5IeSRmaeI4uY=.106152b7-0c27-4964-a9fc-f7f3c74eaa21@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java`, `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java`, `java/beans/XMLDecoder/8028054/TestConstructorFinder.java` and `java/beans/XMLDecoder/8028054/TestMethodFinder.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom is not supported. Also, `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` need "requires vm.jvmti".
> 
> The issue could be reproduced by zero.

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

  XMLDecoder tests are filed in JDK-8291640

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/623e3723..97c38a36

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

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

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


From aoqi at openjdk.org  Mon Aug  1 16:33:27 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 16:33:27 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use the
 3-arg Class.forName
Message-ID: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>

The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 

If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:


--------------------------------------------------
TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
...
Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
	... 9 more
...

--------------------------------------------------
TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
...
Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
	... 9 more
...
--------------------------------------------------

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

Commit messages:
 - 8291640: java/beans/XMLDecoder/8028054/Task.java should use the 3-arg Class.forName

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

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


From aoqi at openjdk.org  Mon Aug  1 16:34:55 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Mon, 1 Aug 2022 16:34:55 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations"
In-Reply-To: <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <OCSSGoHWUsY8ykzjvyTD0l_PVQ1t_wNAr_nHjEJwt6A=.4334d451-2e2a-4124-8368-353e93c682fe@github.com>
 <jFWYpotVY4kVV8kdBiHLmOHdqorLBN_BEUc2dyLp-qM=.2b18f846-440a-476b-8896-2327438b5c64@github.com>
 <W1mrQwalloPPE97n9DdjV_Vv3jKepWZrrScjP9nO2hM=.86c1a44e-a099-4f21-a8ef-3bfabf8a8f1d@github.com>
Message-ID: <51V8ClPS3vEJ9ZwkzJZwiBUTQsJx5XPRLPY_z8IfSxQ=.9d5d5def-5e1d-459a-b0d7-b3e412c546bb@github.com>

On Mon, 1 Aug 2022 15:54:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Since these two kinds (`jvmti` and `XMLDecoder` tests) of the fix are a little different, should I split this issue into two?
> 
> I think it would be better to split them.

XMLDecoder tests are filed: https://bugs.openjdk.org/browse/JDK-8291640. This issue was also updated.

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

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


From angorya at openjdk.org  Mon Aug  1 16:39:59 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Aug 2022 16:39:59 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
Message-ID: <2CdQkI1wtw8B3I_AwBwoFKJMsbmxip5HL-9nSOW5iko=.c90cecaf-182c-4cd3-b444-b106a335cd63@github.com>

On Thu, 28 Jul 2022 10:08:24 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   creating and deleting test files dynamically

looks good.

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

Marked as reviewed by angorya (no project role).

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


From angorya at openjdk.org  Mon Aug  1 16:40:04 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Aug 2022 16:40:04 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <X_lUfQM50BdLgWCBZBddAEKhzayn1ymRwCZiCHxr-x0=.b84ec065-026e-457e-9d4e-ef04e78b65d8@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>
 <X_lUfQM50BdLgWCBZBddAEKhzayn1ymRwCZiCHxr-x0=.b84ec065-026e-457e-9d4e-ef04e78b65d8@github.com>
Message-ID: <kxVcNpqvKtB0HBFaqMMPJwwu6eN638E8FU1aFTLklVM=.31125a86-0b41-485c-a8a8-9980e55326e2@github.com>

On Thu, 28 Jul 2022 16:19:50 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1205:
>> 
>>> 1203:                 } else {
>>> 1204:                     double kbVal = formatToDoubleValue(len);
>>> 1205:                     len = (long)kbVal;
>> 
>> This code still looks sus to me - there is no need to assign len (it goes out of scope pretty quickly) and formatToDoubleValue() should just format and return a formatted String.
>
> As the returned value has been used in comparison with 1000.0 , so returning a double value from formatToDoubleValue().

Perhaps we should mention in the comments that this code block is only relevant for ubuntu, and we'll be using base 1000 for the formatting.

The following test produces the same formatted values as ubuntu: 


package goryachev.test;

import java.text.DecimalFormat;
import java.text.MessageFormat;

public class TestFileChooser {
    private boolean listViewWindowsStyle;
    double baseFileSize = 1000.0;
    String kiloByteString = "{0} KB";
    String megaByteString = "{0} MB";
    String gigaByteString = "{0} GB";
    private static final long MEBI = 1_000_000L;
    private static final long MEGA = 1024L * 1024L;
    private static final long GIBI = 1_000_000_000L;
    
    public static void main(String[] args) {
        t(0, "0 KB");
        t(1, "1 KB");
        t(999, "1 KB");
        t(1000, "1 KB");
        t(1001, "1 KB");
        t(1023, "1 KB");
        t(1024, "1 KB");
        t(1025, "1 KB");
        t(1026, "1 KB");
        
        t(1449, "1.4 KB");
        t(1450, "1.4 KB");
        t(1451, "1.5 KB");
        t(1500-1, "1.5 KB");
        t(1500, "1.5 KB");
        t(1500+1, "1.5 KB");
        
        t(MEBI-1, "1 MB");
        t(MEBI, "1 MB");
        t(MEBI+1, "1 MB");
        t(MEGA-1, "1 MB");
        t(MEGA, "1 MB");
        t(MEGA+1, "1 MB");
        
        t(GIBI-1, "1 GB");
        t(GIBI, "1 GB");
        t(GIBI+1, "1 GB");
        
        t(GIBI + 500_000_000L, "1.5 GB");
        t(GIBI + 600_000_000L, "1.6 GB");
        
        System.err.println("OK");
    }
    
    public static void t(long len, String expected) {
        String res = new TestFileChooser().format(len);
        if (!expected.equals(res)) {
            System.err.println("expected=" + expected + " got=" + res + " for len=" + len);
        }
    }
    
    public String format(long len) {
        String text;
        if (listViewWindowsStyle) {
            if (len == 0) {
                text = MessageFormat.format(kiloByteString, len);
            } else {
                len /= 1000L;
                text = MessageFormat.format(kiloByteString, len + 1);
            }
        } else if (len < 1000L) {
            text = MessageFormat.format(kiloByteString, (len==0 ? 0L : 1L));
        } else {
            double kbVal = formatToDoubleValue(len);
            len = (long)kbVal;
            if (kbVal < baseFileSize) {
                text = MessageFormat.format(kiloByteString, kbVal);
            } else {
                double mbVal = formatToDoubleValue(len);
                len = (long)mbVal;
                if (mbVal < baseFileSize) {
                    text = MessageFormat.format(megaByteString, mbVal);
                } else {
                    double gbVal = formatToDoubleValue(len);
                    text = MessageFormat.format(gigaByteString, gbVal);
                }
            }
        }
        return text;
    }
    
    public double formatToDoubleValue(long len) {
        DecimalFormat df = new DecimalFormat("0.0");
        double val = len/baseFileSize;
        return  Double.valueOf(df.format(val));
    }
}

>> src/java.desktop/share/classes/sun/swing/FilePane.java line 1215:
>> 
>>> 1213:                         } else {
>>> 1214:                             double gbVal = formatToDoubleValue(len);
>>> 1215:                             text = MessageFormat.format(gigaByteString, gbVal);
>> 
>> should we also handle "{0} TB" cases?
>
> As discussed in meeting , Phil has suggested Files having "TB" sizes won't be handled now.

ok

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

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


From angorya at openjdk.org  Mon Aug  1 16:40:05 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Mon, 1 Aug 2022 16:40:05 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <kxVcNpqvKtB0HBFaqMMPJwwu6eN638E8FU1aFTLklVM=.31125a86-0b41-485c-a8a8-9980e55326e2@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>
 <X_lUfQM50BdLgWCBZBddAEKhzayn1ymRwCZiCHxr-x0=.b84ec065-026e-457e-9d4e-ef04e78b65d8@github.com>
 <kxVcNpqvKtB0HBFaqMMPJwwu6eN638E8FU1aFTLklVM=.31125a86-0b41-485c-a8a8-9980e55326e2@github.com>
Message-ID: <THLrtagB7R-39CpA_AMw4uPyg3Q3Z6olj1GvHTXynHA=.02c532cd-1b41-4ffa-8730-ae25abb2e7b5@github.com>

On Mon, 1 Aug 2022 16:18:00 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> As the returned value has been used in comparison with 1000.0 , so returning a double value from formatToDoubleValue().
>
> Perhaps we should mention in the comments that this code block is only relevant for ubuntu, and we'll be using base 1000 for the formatting.
> 
> The following test produces the same formatted values as ubuntu: 
> 
> 
> package goryachev.test;
> 
> import java.text.DecimalFormat;
> import java.text.MessageFormat;
> 
> public class TestFileChooser {
>     private boolean listViewWindowsStyle;
>     double baseFileSize = 1000.0;
>     String kiloByteString = "{0} KB";
>     String megaByteString = "{0} MB";
>     String gigaByteString = "{0} GB";
>     private static final long MEBI = 1_000_000L;
>     private static final long MEGA = 1024L * 1024L;
>     private static final long GIBI = 1_000_000_000L;
>     
>     public static void main(String[] args) {
>         t(0, "0 KB");
>         t(1, "1 KB");
>         t(999, "1 KB");
>         t(1000, "1 KB");
>         t(1001, "1 KB");
>         t(1023, "1 KB");
>         t(1024, "1 KB");
>         t(1025, "1 KB");
>         t(1026, "1 KB");
>         
>         t(1449, "1.4 KB");
>         t(1450, "1.4 KB");
>         t(1451, "1.5 KB");
>         t(1500-1, "1.5 KB");
>         t(1500, "1.5 KB");
>         t(1500+1, "1.5 KB");
>         
>         t(MEBI-1, "1 MB");
>         t(MEBI, "1 MB");
>         t(MEBI+1, "1 MB");
>         t(MEGA-1, "1 MB");
>         t(MEGA, "1 MB");
>         t(MEGA+1, "1 MB");
>         
>         t(GIBI-1, "1 GB");
>         t(GIBI, "1 GB");
>         t(GIBI+1, "1 GB");
>         
>         t(GIBI + 500_000_000L, "1.5 GB");
>         t(GIBI + 600_000_000L, "1.6 GB");
>         
>         System.err.println("OK");
>     }
>     
>     public static void t(long len, String expected) {
>         String res = new TestFileChooser().format(len);
>         if (!expected.equals(res)) {
>             System.err.println("expected=" + expected + " got=" + res + " for len=" + len);
>         }
>     }
>     
>     public String format(long len) {
>         String text;
>         if (listViewWindowsStyle) {
>             if (len == 0) {
>                 text = MessageFormat.format(kiloByteString, len);
>             } else {
>                 len /= 1000L;
>                 text = MessageFormat.format(kiloByteString, len + 1);
>             }
>         } else if (len < 1000L) {
>             text = MessageFormat.format(kiloByteString, (len==0 ? 0L : 1L));
>         } else {
>             double kbVal = formatToDoubleValue(len);
>             len = (long)kbVal;
>             if (kbVal < baseFileSize) {
>                 text = MessageFormat.format(kiloByteString, kbVal);
>             } else {
>                 double mbVal = formatToDoubleValue(len);
>                 len = (long)mbVal;
>                 if (mbVal < baseFileSize) {
>                     text = MessageFormat.format(megaByteString, mbVal);
>                 } else {
>                     double gbVal = formatToDoubleValue(len);
>                     text = MessageFormat.format(gigaByteString, gbVal);
>                 }
>             }
>         }
>         return text;
>     }
>     
>     public double formatToDoubleValue(long len) {
>         DecimalFormat df = new DecimalFormat("0.0");
>         double val = len/baseFileSize;
>         return  Double.valueOf(df.format(val));
>     }
> }

Looks like it matches on ubuntu.  

Do we care about other linuxes / desktop environments / file browsers?

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

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


From prr at openjdk.org  Mon Aug  1 17:41:05 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 17:41:05 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v5]
In-Reply-To: <aAd-YjYnJ3d0mVt1ApwCvGWWUjU7Ot2mGHqjzya07FQ=.24e6f661-4f9c-4935-832c-17d0e82301e8@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <Cv5J_ReeVFyd56W9tPkXgzpzdcxYtW6SWTxZeF9HiSc=.6c8cd2eb-caa2-4339-a711-52267be76249@github.com>
 <AIus88g7s308GZyyZqbVihnnW_0glFFsba_sNFQkBaw=.eb76407b-017a-4d3a-9105-bd9fbc7d11f8@github.com>
 <aAd-YjYnJ3d0mVt1ApwCvGWWUjU7Ot2mGHqjzya07FQ=.24e6f661-4f9c-4935-832c-17d0e82301e8@github.com>
Message-ID: <ykW3gYkfoXFekJnV3FJzmw9eK420snghtUsXY2FPAuA=.bcd84c7a-55e7-4b81-875d-a3e0bc6a3a33@github.com>

On Mon, 1 Aug 2022 06:17:33 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 87:
>> 
>>> 85:         //  directly.
>>> 86:         StackWalker walker = StackWalker.getInstance(StackWalker.Option.RETAIN_CLASS_REFERENCE);
>>> 87:         if ((graphics == null) && (walker.getCallerClass() != this.getClass())) {
>> 
>> I don't know if creating a StackWalker is expensive but I think it should be done only if graphics == null
>> 
>> Also the version of getInstance() being called here might throw SecurityException
>> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getInstance(java.lang.StackWalker.Option)
>> 
>> So you'll need to wrap it in a doPrivileged.
>
> @prrace Then I will proceed by removing Stackwalker and create a graphics instance only if its `null`.

No, because that won't work, or more precisely will be a waste of work.
See
DebugGraphics(Graphics graphics) {
this(); // << no-args constructor and graphics will still be null
this.graphics = null;
}

graphics will ALWAYS be null when you come via here which is exactly why we needed StackWalker

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

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


From avu at openjdk.org  Mon Aug  1 17:51:58 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 1 Aug 2022 17:51:58 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline
In-Reply-To: <M7cubXskcQYIJ_F8i-UfmMRgl2tlZTYUZy6XqmX1Lmk=.f35f88ca-fc05-4b92-928a-43597afedf5d@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
 <M7cubXskcQYIJ_F8i-UfmMRgl2tlZTYUZy6XqmX1Lmk=.f35f88ca-fc05-4b92-928a-43597afedf5d@github.com>
Message-ID: <rk0is4t4zBEVdDYeouA2ii_XYQMv2x6mtrtfReS0AHY=.1e8c5e72-cac1-4fbf-860a-22699658769a@github.com>

On Fri, 22 Jul 2022 18:59:21 GMT, Phil Race <prr at openjdk.org> wrote:

>  Looking at the RenderPerfTest numbers ClipFlatOvalAA went down .. but everything else improved by at the very least a statistically significant amount so why did that one test get worse ?

I'm unable to re-run the testing because of a regression [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266). I'll be back to this pull request after resolving the regression.

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

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


From prr at openjdk.org  Mon Aug  1 18:19:50 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 18:19:50 GMT
Subject: RFR: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified [v8]
In-Reply-To: <qWdUVLnfkWUtF5NGTKpfoLUINLnomgam3PbfnYe3IgQ=.8b263989-96b5-4576-9ad1-d94067f1a6e4@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
 <qWdUVLnfkWUtF5NGTKpfoLUINLnomgam3PbfnYe3IgQ=.8b263989-96b5-4576-9ad1-d94067f1a6e4@github.com>
Message-ID: <-9cMJtl-6lWLwNPqJWTVy7lI7RQ716ozptWUfcQfD8w=.4b07dfe6-c902-4b99-be2e-1f0a38003bb5@github.com>

On Tue, 26 Jul 2022 05:57:24 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JLabel and AbstractButton's imageUpdate method description updated.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   param added to JLabel's imageUpdate method

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Mon Aug  1 22:37:50 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 22:37:50 GMT
Subject: RFR: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB) [v8]
In-Reply-To: <MffVEaVcelIOX62iYehvHzBPLurM8F8RRQNWb79NB3A=.1ad71f5c-d9ca-44ba-a88d-bb4b8097f0af@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
 <MffVEaVcelIOX62iYehvHzBPLurM8F8RRQNWb79NB3A=.1ad71f5c-d9ca-44ba-a88d-bb4b8097f0af@github.com>
Message-ID: <uWAl7CFdW7y6-CS9un8W0Q_Ojl-W1Hb0jJ2sDXMVXuk=.3b52124f-df47-4faa-a0c0-47e7c20c7777@github.com>

On Fri, 29 Jul 2022 11:37:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
>> This is because
>> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
>> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
>> 
>> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
>> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
>> 
>> No regression test is added as it involves using filesize of >2GB.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rectify assignment

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Mon Aug  1 22:46:11 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 22:46:11 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS [v2]
In-Reply-To: <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
Message-ID: <Hoj0dhmTf8_H-cqvCfcVuwFEYf0TWtFiZwPXTShrqG8=.886bb939-9345-4b6b-ac03-fd2d058f64d2@github.com>

On Mon, 1 Aug 2022 14:30:54 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
>> 
>> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
>> 
>> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made DrawRotatedStringUsingRotatedFont.java headful and dropped extra test

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Mon Aug  1 22:46:12 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 22:46:12 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <x0mBtfwIQfOr4RCYSW-N6triak3GmnYrKW4cnV-_cts=.45090aa9-4573-41d3-9e8b-9834e29d52d3@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <x0mBtfwIQfOr4RCYSW-N6triak3GmnYrKW4cnV-_cts=.45090aa9-4573-41d3-9e8b-9834e29d52d3@github.com>
Message-ID: <UZFP3ysYxngSNwDC9pu1sxbbqro7NdR7w8JZWH3sHdI=.d111c671-d336-41cd-ab8a-7659b6fd8960@github.com>

On Mon, 1 Aug 2022 14:21:53 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> On the issue of the second test, I still believe it is useful:
> 
> * it demonstrates a legitimate problem with `Disposer`, albeit admittedly a different one than reported in the bug,
> * it shows the problem more clearly as the problematic usage pattern of `Disposer` is contained in the test itself and not buried in JDK code,
> * it crashes more reliably,
> * it shows that the problem (at least potentially) exists on Linux also,
> * it does not have to be marked headful.

I think it might help us ensure that such a problem will not actually creep in, but I think it
is testing a scenario that is not the cause of the crash etc. However I suppose in the end
all our passing tests are testing things that aren't a problem right now  ! .. so OK ..

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

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


From prr at openjdk.org  Mon Aug  1 22:52:52 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 22:52:52 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <RzARYHG0jJJZm-EExZ4T_eITO9lJTQXAJWi9vidinjA=.2b597369-2406-43ad-a611-5d8eb8860193@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Looks fine to me. However the langtools / javadoc folks seem like they should be primary reviewers since it is mostly messages from the tools.

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

Marked as reviewed by prr (Reviewer).

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


From prr at openjdk.org  Mon Aug  1 23:03:40 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 1 Aug 2022 23:03:40 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
Message-ID: <sPxKayk9cSIcPXVlCwgn6EkxMxxwyAzeF_qR9xz8O4o=.91753a41-9e62-417a-b711-42bc0a7242b0@github.com>

On Mon, 1 Aug 2022 16:23:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
> 
> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
> 
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> --------------------------------------------------

@AlanBateman - This seems very odd to me. Why does it fail and why does this alternate incantation work ?
And how would one ever have known the latter would work without some Loom knowledge ?

There's nothing here : https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Class.html#forName(java.lang.String)
that suggests any spec change to Class.forName(String) ..

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

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


From tr at openjdk.org  Tue Aug  2 04:44:43 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Aug 2022 04:44:43 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v5]
In-Reply-To: <ykW3gYkfoXFekJnV3FJzmw9eK420snghtUsXY2FPAuA=.bcd84c7a-55e7-4b81-875d-a3e0bc6a3a33@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <Cv5J_ReeVFyd56W9tPkXgzpzdcxYtW6SWTxZeF9HiSc=.6c8cd2eb-caa2-4339-a711-52267be76249@github.com>
 <AIus88g7s308GZyyZqbVihnnW_0glFFsba_sNFQkBaw=.eb76407b-017a-4d3a-9105-bd9fbc7d11f8@github.com>
 <aAd-YjYnJ3d0mVt1ApwCvGWWUjU7Ot2mGHqjzya07FQ=.24e6f661-4f9c-4935-832c-17d0e82301e8@github.com>
 <ykW3gYkfoXFekJnV3FJzmw9eK420snghtUsXY2FPAuA=.bcd84c7a-55e7-4b81-875d-a3e0bc6a3a33@github.com>
Message-ID: <Bq6MX_fu6k5hlC3NWyfwmrqal2MXGX-1SOsPBk5zYwE=.3bd7b83a-3c8d-469c-9e23-ab93c38f6230@github.com>

On Mon, 1 Aug 2022 17:36:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace Then I will proceed by removing Stackwalker and create a graphics instance only if its `null`.
>
> No, because that won't work, or more precisely will be a waste of work.
> See
> DebugGraphics(Graphics graphics) {
> this(); // << no-args constructor and graphics will still be null
> this.graphics = null;
> }
> 
> graphics will ALWAYS be null when you come via here which is exactly why we needed StackWalker

Ok, then we should set graphics only If the no-args constructor is called by another program and not via by the same class.

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

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


From aoqi at openjdk.org  Tue Aug  2 06:32:09 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Tue, 2 Aug 2022 06:32:09 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
> 
> The issue could be reproduced by zero.

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

 - Merge branch 'master' into 8291508
 - XMLDecoder tests are filed in JDK-8291640
 - XMLDecoder update
   
   Co-authored-by: Alan Bateman <alanb at openjdk.org>
 - 8291508: Fix some tests with "requires vm.continuations"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/97c38a36..1e00cd83

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

  Stats: 2659 lines in 193 files changed: 1590 ins; 605 del; 464 mod
  Patch: https://git.openjdk.org/jdk/pull/9677.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9677/head:pull/9677

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


From alanb at openjdk.org  Tue Aug  2 06:38:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 06:38:22 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
Message-ID: <wDTirAPqkb8DXSKl2i3VKF2IgbobjI_IMotJ_UdrGd8=.cc09d673-c3d0-4824-a5d1-ee4f6cdaa49b@github.com>

On Mon, 1 Aug 2022 16:23:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
> 
> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
> 
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> --------------------------------------------------

The two XMLDecoder tests in this directory are problematic because they directly load and cause the initialization of all classes in java.base/java.lang, including non-public classes such as java.lang.VirtualThread$VThreadContinuation. Loading and initialization of this class requires the loading and initialization of its super class that is our implementation of delimited continuations and is deeply tied to VM support. The Zero port doesn't have this support and instead uses an alternative implementation of virtual threads where each virtual thread is bound to an OS thread.

So no change to Class.forName, instead we are just modifying the two tests so that they don't needless try to initialize JDK internal classes that are dependent on VM support.

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

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


From tr at openjdk.org  Tue Aug  2 06:51:36 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Aug 2022 06:51:36 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v7]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/d9d62c86..8f5cfb50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9673&range=05-06

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

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


From psadhukhan at openjdk.org  Tue Aug  2 06:52:55 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 2 Aug 2022 06:52:55 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide previously
 visible tab component [v2]
In-Reply-To: <VDP6V8PuELQ3JqT5pHV3aa0VdBayUlF5wMcrJJMYQSk=.a09ad2c2-4552-4c26-905d-6ba93e00a27b@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
 <VDP6V8PuELQ3JqT5pHV3aa0VdBayUlF5wMcrJJMYQSk=.a09ad2c2-4552-4c26-905d-6ba93e00a27b@github.com>
Message-ID: <nWJvOYuPlvzfTDzYfGdZ_P1XA7b1f5QBlWLZx8gdY6c=.6f47dcb1-cd44-407d-9be4-efc738e6edf5@github.com>

On Sat, 30 Jul 2022 00:28:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> A simple change listener is used in JTabbedPane to lazily fill with components - this is done by adding the components to JTabbedPane using the `setComponentAt` in the change listener.
>> 
>> Previously, if the change listener was placed before calling `addTab()` , the previous visible component was overlapping with the current visible component. To fix it, the visibility of previous component is set to false before the current component's visibility is set to true in `setComponentAt`.
>> 
>> Following are the before and after fix screenshots-
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/181658303-ff3a7df7-5af6-4e76-a103-45d4d76480c3.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug id changed, added isVisible check

Marked as reviewed by psadhukhan (Reviewer).

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

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


From psadhukhan at openjdk.org  Tue Aug  2 06:52:58 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 2 Aug 2022 06:52:58 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide previously
 visible tab component [v2]
In-Reply-To: <yElNBRXFSX1iOiSD-kGyYgGGl2zaDV8cLC_OHO9W8Ug=.96604f59-2f41-4b0d-82c9-a9089f5d5b3c@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
 <cHU2mKahjQKn5zHRk91Z4RTYuj4a-GsiR1-LY37hA6w=.e98f537d-f42f-450c-8f34-a41c4e5d9902@github.com>
 <yElNBRXFSX1iOiSD-kGyYgGGl2zaDV8cLC_OHO9W8Ug=.96604f59-2f41-4b0d-82c9-a9089f5d5b3c@github.com>
Message-ID: <yf_1j9UzSJJkIsIk9WBnskCrIkaI1GDqkS6b6EFJHa4=.18fcd975-89a8-432d-90b2-7f3e8522174b@github.com>

On Sat, 30 Jul 2022 00:27:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTabbedPane.java line 1603:
>> 
>>> 1601:                 if (this.visComp != null &&
>>> 1602:                         !this.visComp.equals(component)) {
>>> 1603:                     // previous component visibility is set to false
>> 
>> It seems `isVisible` is checked before changing the visibility..Should we do it here too?
>
> I thought it might be redundant since the setVisible() checks for visibility of component within show() and hide(). But to add clarity I have add `isVisible` check.

It seems this check is followed in this class
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L390
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L419

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

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


From alanb at openjdk.org  Tue Aug  2 06:56:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 06:56:55 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
Message-ID: <SH61rVjJMYU3UUM1oh3xCLk0ev13zOfxr1wx97gvLqU=.fbe65bc3-adac-431c-8389-e3546bbdbc6c@github.com>

On Mon, 1 Aug 2022 16:23:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
> 
> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
> 
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> --------------------------------------------------

One other comment on this is that the proposed change should mean that the tests no longer need to run with --enable-preview.

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

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


From sspitsyn at openjdk.org  Tue Aug  2 06:59:24 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 Aug 2022 06:59:24 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <RgSuOV1j5nPaotE4O96x5QU2Ab8R8corK5vCbsHzBXk=.288a6bf5-6d43-4954-8d90-b4cac8e4c5e7@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291508
>  - XMLDecoder tests are filed in JDK-8291640
>  - XMLDecoder update
>    
>    Co-authored-by: Alan Bateman <alanb at openjdk.org>
>  - 8291508: Fix some tests with "requires vm.continuations"

I'm surprised these two tests have the `--enable-preview` flag.
@lmesnik Could you, please, take a look at these two tests?
Otherwise, the fix looks good to me.
Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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


From psadhukhan at openjdk.org  Tue Aug  2 10:46:49 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 2 Aug 2022 10:46:49 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in a
 button.
Message-ID: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>

It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the letter 'S' in the JButton to be underlined if JButton's text has 'S' in its string.
This is because [**VK_F4**](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506) keycode is 0x73 (115 in decimal) which happens to be value of lowercase [**'s'** ](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(), the first index of the character (either lowecasr or uppercase) is returned as a mnemonic, which gets underlined.

Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic which corresponds to lowercase p->z

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

Commit messages:
 - Fix
 - Fix
 - 4850101: Setting mnemonic to VK_F4 underlines the letter S in a button.

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

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


From duke at openjdk.org  Tue Aug  2 11:56:06 2022
From: duke at openjdk.org (Dio Brando)
Date: Tue, 2 Aug 2022 11:56:06 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in
 a button.
In-Reply-To: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
Message-ID: <Wb_z2GD_CUzKdsJWvH2AwIu4heBKb2JHQOLcV_IUVFE=.b225960d-cada-4d44-bbbb-ab749a3c9774@github.com>

On Tue, 2 Aug 2022 10:22:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the letter 'S' in the JButton to be underlined if JButton's text has 'S' in its string.
> This is because [**VK_F4**](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506) keycode is 0x73 (115 in decimal) which happens to be value of lowercase [**'s'** ](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(), the first index of the character (either lowecasr or uppercase) is returned as a mnemonic, which gets underlined.
> 
> Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic which corresponds to lowercase p->z

Marked as reviewed by AJ1032480 at github.com (no known OpenJDK username).

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

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


From alanb at openjdk.org  Tue Aug  2 17:27:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 17:27:25 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291508
>  - XMLDecoder tests are filed in JDK-8291640
>  - XMLDecoder update
>    
>    Co-authored-by: Alan Bateman <alanb at openjdk.org>
>  - 8291508: Fix some tests with "requires vm.continuations"

Just an FYI that the [ORDER OF TAGS](https://openjdk.org/jtreg/tag-spec.html#ORDER) section of the tag language spec recommends putting the `@requires` before the `@modules` and `@library` tags.

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

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


From asemenov at openjdk.org  Tue Aug  2 18:09:50 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 2 Aug 2022 18:09:50 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2]
In-Reply-To: <ewONNnnTWn_Xx8yiBFr9fDW0lhiEB1foc3neWCLBx3Q=.66ee5596-bcc4-4a54-a4ae-6cb0b0b94424@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
 <W-gPd9B3KJ93VMBlZBevuKyQxbkH4TQKeo4l7Pypvn4=.4e031c21-9daf-4d47-8342-341a8a2adf30@github.com>
 <ewONNnnTWn_Xx8yiBFr9fDW0lhiEB1foc3neWCLBx3Q=.66ee5596-bcc4-4a54-a4ae-6cb0b0b94424@github.com>
Message-ID: <O1vHfmf8cC12C8ti4LBfcPK0GRcjrmiE8YJXxGD_9Nk=.9f49aa2f-5de6-4a6f-bc0b-73109eb3cffd@github.com>

On Fri, 15 Jul 2022 18:19:33 GMT, Phil Race <prr at openjdk.org> wrote:

>> @azuev-java @prrace  please review this CSR ticket [JDK-8286674](https://bugs.openjdk.org/browse/JDK-8286674)
>
>> @azuev-java @prrace please review this CSR ticket [JDK-8286674](https://bugs.openjdk.org/browse/JDK-8286674)
> 
> Before we get to that
> 1) You did not acknowledge this is not a backportable fix
> 2) I'd like you to explain why calling setSelectedIndex isn't good enough AND why Windows A11Y does not need this API
> 3) It is incorrect to add the csr as an issue - skara tooling has made it an integration blocker.

@prrace Thanks a lot.
I updated the CSR ticket, and added information there, including your question.

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

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


From duke at openjdk.org  Tue Aug  2 18:20:55 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 2 Aug 2022 18:20:55 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v13]
In-Reply-To: <THLrtagB7R-39CpA_AMw4uPyg3Q3Z6olj1GvHTXynHA=.02c532cd-1b41-4ffa-8730-ae25abb2e7b5@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <nr-jdKWYjcGNv8hDGAWtifbtZM1-Vre6NacLH0iq9lU=.bb7f4fc0-57cf-493b-80fa-eb81fddd3954@github.com>
 <HVZXJZ3zm9S-8ohuUQJBfjoykc-2mjta6YR9gO9iWNU=.6b403f8f-91c6-4771-bd02-e2f8fa69d96a@github.com>
 <X_lUfQM50BdLgWCBZBddAEKhzayn1ymRwCZiCHxr-x0=.b84ec065-026e-457e-9d4e-ef04e78b65d8@github.com>
 <kxVcNpqvKtB0HBFaqMMPJwwu6eN638E8FU1aFTLklVM=.31125a86-0b41-485c-a8a8-9980e55326e2@github.com>
 <THLrtagB7R-39CpA_AMw4uPyg3Q3Z6olj1GvHTXynHA=.02c532cd-1b41-4ffa-8730-ae25abb2e7b5@github.com>
Message-ID: <-thVMWDZS8HI0Hlqa5HAt9uVRI-SthoG2jduIFLjkqY=.26da10de-f4c1-43a1-8501-1014ab9b1850@github.com>

On Mon, 1 Aug 2022 16:35:44 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

> Looks like it matches on ubuntu.
> 
> Do we care about other linuxes / desktop environments / file browsers?

I checked in Oracle Linux and it is showing file size similar to native.

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

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


From duke at openjdk.org  Tue Aug  2 18:52:54 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 2 Aug 2022 18:52:54 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <2CdQkI1wtw8B3I_AwBwoFKJMsbmxip5HL-9nSOW5iko=.c90cecaf-182c-4cd3-b444-b106a335cd63@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
 <2CdQkI1wtw8B3I_AwBwoFKJMsbmxip5HL-9nSOW5iko=.c90cecaf-182c-4cd3-b444-b106a335cd63@github.com>
Message-ID: <INgGn2wMBzsyYe16GjcaQE6VrUaRPF39c5jjGy_2m4A=.c49adbac-3c4b-4a9e-a668-c82312239c9e@github.com>

On Mon, 1 Aug 2022 16:36:13 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   creating and deleting test files dynamically
>
> looks good.

@andy-goryachev-oracle Checked in Oracle Linux and it shows file size similar to native.

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

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


From lmesnik at openjdk.org  Tue Aug  2 18:53:43 2022
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 2 Aug 2022 18:53:43 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
Message-ID: <9udmozwzmOEm5-cfI85oeAVTafamwMrZj1-Y2q6mxLA=.1708e4bf-24ec-4d5b-9859-7129342628ab@github.com>

On Tue, 2 Aug 2022 06:32:09 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into 8291508
>  - XMLDecoder tests are filed in JDK-8291640
>  - XMLDecoder update
>    
>    Co-authored-by: Alan Bateman <alanb at openjdk.org>
>  - 8291508: Fix some tests with "requires vm.continuations"

Marked as reviewed by lmesnik (Reviewer).

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

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


From dnguyen at openjdk.org  Tue Aug  2 19:07:40 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 2 Aug 2022 19:07:40 GMT
Subject: RFR: 8064787: [macosx] In Nimbus LaF,
 Ctrl+Alt mnemonic doesn't work
In-Reply-To: <4vAsS8jNSMRplL9t7DYP3sZlYGU9VRUIk_uxSpO5JfE=.0347e9c2-4737-463e-895e-895b1c1cc613@github.com>
References: <4vAsS8jNSMRplL9t7DYP3sZlYGU9VRUIk_uxSpO5JfE=.0347e9c2-4737-463e-895e-895b1c1cc613@github.com>
Message-ID: <ozqns75-BdT6MdMzzAWBhE8DNbBlCyAZlTNYJ6DeN5Y=.c731392d-b8a7-4558-a9ee-8b39a75690bd@github.com>

On Thu, 14 Jul 2022 08:03:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In SwingSet2 application, "File" menu has a visible mnemonic set on F.
> 
> ![image](https://user-images.githubusercontent.com/43534309/178932400-ab70602a-9c4f-4cab-b3b7-0508b26d2ebe.png)
> 
> Now, in MacOS, with Aqua, Java (Metal), and Motif LaF, one can open the menu pressing Ctrl+Alt+F. 
> But with Nimbus L&F, to open File menu, you have to press Alt+F even on OS X.
> 
> It should work with Ctrl+Alt+F as sun/lwawt/macosx/LWCToolkit.java. getFocusAcceleratorKeyMask() 
> has CTRL_MASK | ALT_MASK
> 
> Fix is to add Menu.shortcutKeys in SynthLookAndFeel default table so that it can call SwingUtilities2.getSystemMnemonicKeyMask() which will call either LWCToolkit.getFocusAcceleratorKeyMask() or SunToolkit.getFocusAcceleratorKeyMask() depending on platform.
> 
> No regression test is added as it can be checked with SwingSet2 app.

Applied change locally and tested on SwingSet2. Nimbus now behaves like the other L&Fs described.

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

Marked as reviewed by dnguyen (Author).

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


From aivanov at openjdk.org  Tue Aug  2 20:10:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Aug 2022 20:10:42 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
Message-ID: <olkA3_rOphPBY57Dbws7FoIgbfOrwZ1fo8Iz1uA2des=.09e5699c-181d-4c81-b641-476c1fe1caf8@github.com>

On Thu, 21 Jul 2022 00:27:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added screen insets to account for taskbar position, doc changes

I don't `JSplitPane` is a bad idea, rather the opposite: it's a good idea. It encapsulates a `JPanel` as a container for test UI. If a test doesn't add UI to that area (via a callback, or lambda or method reference, or any other way), the instructions UI could be left as the sole content of the frame. Otherwise, `JSplitPane` will separate the parts in the frame and will allow changing the size of the panes. It also mimics the original positioning strategy: vertical/horizontal.

In some tests, the test UI consists of a single button only. I think a single window for such test UI would work better than two separate and independent frames. One frame is easier to manage.

I was thinking about merging instructions and test UI from the start. Yet using two frames / windows seemed easier to implement.

Some test cases may not fit into either pattern. There's always the option to create test UI as needed. Yet positioning of the instruction frame may be an issue. If test creates windows / dialogs owned by the instruction frame, AWT ensures the test UI windows / dialogs are above the instruction frame; however, if test UI is large enough, it could completely overlap the instructions.

I guess some test cases may even be easier to implement and maintain with its own custom UI. Too many options in `PassFailJFrame` could make it harder to use.

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

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


From prr at openjdk.org  Tue Aug  2 20:33:42 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Aug 2022 20:33:42 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <SH61rVjJMYU3UUM1oh3xCLk0ev13zOfxr1wx97gvLqU=.fbe65bc3-adac-431c-8389-e3546bbdbc6c@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <SH61rVjJMYU3UUM1oh3xCLk0ev13zOfxr1wx97gvLqU=.fbe65bc3-adac-431c-8389-e3546bbdbc6c@github.com>
Message-ID: <4_tM2zGhsWXglCYtdZqgGXMHreTRhRYnXVVgo8TvOM8=.91d4ddf2-70c7-43f5-bdc2-77a290c5d70c@github.com>

On Tue, 2 Aug 2022 06:52:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> One other comment on this is that the proposed change should mean that the tests no longer need to run with --enable-preview.

You've lost me all over again.
Why did these two tests need that in the first place and why would they no longer need it ?

My best guess is that it was added so that the tests deliberately provoked using continuations to verify everything worked but that with the change there's no point since it won't load any classes that use them .. ?

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

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


From aoqi at openjdk.org  Wed Aug  3 02:34:48 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 3 Aug 2022 02:34:48 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v5]
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
> 
> The issue could be reproduced by zero.

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

  update tags order

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9677/files
  - new: https://git.openjdk.org/jdk/pull/9677/files/1e00cd83..2ea9e1a9

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

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

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


From aoqi at openjdk.org  Wed Aug  3 02:36:03 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 3 Aug 2022 02:36:03 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v4]
In-Reply-To: <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <DAz_UxOMdnm7rPmXBQwyOfcE4Lk1yh8gTVcnKRmZRsw=.22f26305-9112-42ff-9267-474df3dac175@github.com>
 <NEDVAw3e5SschaUp7J4Wd4H32fM9_ydH8dU_oQst7sc=.af0af663-2b08-4ecc-9130-5415390dd3dd@github.com>
Message-ID: <ga517T_Y4c-YsmdoMXQdVMQMggNA9yVlarfwuL8uCGU=.f20e6093-450d-410b-a85f-f0a9964e8b79@github.com>

On Tue, 2 Aug 2022 17:25:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Just an FYI that the [ORDER OF TAGS](https://openjdk.org/jtreg/tag-spec.html#ORDER) section of the tag language spec recommends putting the `@requires` before the `@modules` and `@library` tags.

Done. Didn't know that. Thank you for the reminder.

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

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


From alanb at openjdk.org  Wed Aug  3 06:01:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 06:01:42 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <4_tM2zGhsWXglCYtdZqgGXMHreTRhRYnXVVgo8TvOM8=.91d4ddf2-70c7-43f5-bdc2-77a290c5d70c@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <SH61rVjJMYU3UUM1oh3xCLk0ev13zOfxr1wx97gvLqU=.fbe65bc3-adac-431c-8389-e3546bbdbc6c@github.com>
 <4_tM2zGhsWXglCYtdZqgGXMHreTRhRYnXVVgo8TvOM8=.91d4ddf2-70c7-43f5-bdc2-77a290c5d70c@github.com>
Message-ID: <VUAwvj9XIcUHj_6p39FQXvmebJhvAh52kbBvcmFFBio=.de2355d0-4d71-4e8e-a53c-aaee8c6865c4@github.com>

On Tue, 2 Aug 2022 20:30:17 GMT, Phil Race <prr at openjdk.org> wrote:

> My best guess is that it was added so that the tests deliberately provoked using continuations to verify everything worked but that with the change there's no point since it won't load any classes that use them .. ?

That's right. These tests triggered the initialization of classes that depend on the VM being started with --enable-preview. With the proposed change here, the classes will be loaded but not initialized so it won't execute code that needs preview features to be enabled.

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

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


From aturbanov at openjdk.org  Wed Aug  3 06:18:57 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 3 Aug 2022 06:18:57 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v7]
In-Reply-To: <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>
Message-ID: <mAHKqVJm6Q3tFuK13xmeZ-eOXdwdaPAQHUPP3_YXfiA=.8ab0bb86-76f6-49a0-b6d6-f15c190c9165@github.com>

On Tue, 2 Aug 2022 06:51:36 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 98:

> 96:             });
> 97: 
> 98:             if(walker.getCallerClass() != this.getClass()) {

Let's add space after `if`

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

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


From tr at openjdk.org  Wed Aug  3 07:54:47 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Aug 2022 07:54:47 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v7]
In-Reply-To: <mAHKqVJm6Q3tFuK13xmeZ-eOXdwdaPAQHUPP3_YXfiA=.8ab0bb86-76f6-49a0-b6d6-f15c190c9165@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>
 <mAHKqVJm6Q3tFuK13xmeZ-eOXdwdaPAQHUPP3_YXfiA=.8ab0bb86-76f6-49a0-b6d6-f15c190c9165@github.com>
Message-ID: <XJsbeqPG0oabcwJO2cTI0EXR-hcEqm0xnwXeWyPur-c=.3341c916-1d8c-462f-9802-258ba1ed43ba@github.com>

On Wed, 3 Aug 2022 06:15:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 98:
> 
>> 96:             });
>> 97: 
>> 98:             if(walker.getCallerClass() != this.getClass()) {
> 
> Let's add space after `if`

Updated.

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

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


From tr at openjdk.org  Wed Aug  3 07:58:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Aug 2022 07:58:18 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v2]
In-Reply-To: <N0aSqPyUYe6_EORrKOnWLadI2Scqz1iFq-skz-XFExQ=.abfc76cf-8b5c-41a5-98ae-633d401282e3@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <N0aSqPyUYe6_EORrKOnWLadI2Scqz1iFq-skz-XFExQ=.abfc76cf-8b5c-41a5-98ae-633d401282e3@github.com>
Message-ID: <VrCGDZiU3LnQwGS3XQ9zmZ4w-GjgOI3duZJtqcXtllM=.b668c8f3-4172-4438-a138-c5a0b20bc9ee@github.com>

On Fri, 29 Jul 2022 18:07:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix : Updated to handle multiSelection case
>>  - Manual Test Indicator Added in JTREG tag
>
> test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 32:
> 
>> 30:             is valid on ValueChanged property listener.
>> 31:    @run main FileChooserSymLinkTest
>> 32: */
> 
> May I ask to place these tags before the class declaration?
> 
> Add the asterisk to each line, like you see in the copyright and other tests.

Updated.

> test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 45:
> 
>> 43: import javax.swing.WindowConstants;
>> 44: 
>> 45: public class FileChooserSymLinkTest{
> 
> Suggestion:
> 
> public class FileChooserSymLinkTest {

Updated.

> test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 76:
> 
>> 74:                 2. Create a Symbolic link targeting the created test directory.
>> 75:                     ex : mklink /D c:\\link c:\\target
>> 76:                 3. In JFileChooser, navigate to "link" created directed.
> 
> ?navigate to directory where you created the link. In this example, to C:\ drive.
> 
> Please use the capital C: for the drive.

Updated.

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

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


From avu at openjdk.org  Wed Aug  3 09:56:19 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 3 Aug 2022 09:56:19 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v12]
In-Reply-To: <-jB87It9Ls537Um6y9hcTwz5OE-WVa-zgsbfCL7GG38=.6cc5e3f3-602f-4fdc-8196-df506c9c0b3a@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <-jB87It9Ls537Um6y9hcTwz5OE-WVa-zgsbfCL7GG38=.6cc5e3f3-602f-4fdc-8196-df506c9c0b3a@github.com>
Message-ID: <ahtRDQzU0edS6VY9zB7m9EJBNqKZheUSeXbpN5EqCdM=.0dd5c410-e292-4aa5-a1f7-7a7cb21ac584@github.com>

On Mon, 1 Aug 2022 11:01:58 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 incrementally with one additional commit since the last revision:
> 
>   Fix rotated text metrics

src/java.desktop/macosx/classes/sun/font/CCompositeGlyphMapper.java line 67:

> 65:     protected int convertToGlyph(int unicode) {
> 66:         int glyph = convertToGlyph(unicode, 0);
> 67: //        setCachedGlyphCode(unicode, glyph);

What's the purpose of the commented line?

src/java.desktop/share/classes/sun/font/StandardGlyphVector.java line 1835:

> 1833: 
> 1834:         void appendGlyphRenderData(int glyphID, GlyphRenderData result, float x, float y) {
> 1835:             // !!! fontStrike needs a method for this.  For that matter, GeneralPath does.

It's better to use well known "TODO" here

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

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


From alanb at openjdk.org  Wed Aug  3 10:52:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 10:52:43 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v5]
In-Reply-To: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
Message-ID: <6hRAKer8eW6kUHAIv-xHtLffshGe2OMmXiJe-wbmdHM=.ab4418e2-f40c-44c0-b546-686f0d09ef74@github.com>

On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update tags order

Marked as reviewed by alanb (Reviewer).

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

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


From aivanov at openjdk.org  Wed Aug  3 13:25:26 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 3 Aug 2022 13:25:26 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v2]
In-Reply-To: <YTO50XW2bmeme1SzMkQCvVciS-wELjEc5CDWATtiBwE=.c855c1fe-299c-44d7-9551-5aac3a861a60@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <YTO50XW2bmeme1SzMkQCvVciS-wELjEc5CDWATtiBwE=.c855c1fe-299c-44d7-9551-5aac3a861a60@github.com>
Message-ID: <Tw_JV5wMS8XBi16aNn5BKCHEDXAHpAf9_3-RIW6MQQY=.8039ccbe-375d-4f4d-a74b-6439d344e187@github.com>

On Mon, 1 Aug 2022 10:27:03 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix : Updated to handle multiSelection case
>  - Manual Test Indicator Added in JTREG tag

It does not work.

In the single-selection case, I see the following output:


Absolute Path : null
Absolute Path : C:\filechooser\link


Above, `null` corresponds to `C:\filechooser\target` folder which is the target of the `link`.

Neither does it work in the multi-selection case:


Absolute Path : C:\filechooser
Absolute Path : null
Absolute Path : C:\filechooser\target


But now it doesn't work in a different way: `link` is reported as `null`.


I can't see none of the comments addressed in the test even though you explicitly added comments that you updated the code. A missing push?

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 59:

> 57:                 } catch (InvocationTargetException e) {
> 58:                     throw new RuntimeException(e);
> 59:                 }

The handlers are the same, collapse the catch block into one which handles both exceptions.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 64:

> 62: 
> 63:         robot.delay(2000);
> 64:         robot.waitForIdle();

Robot is not required. You can safely remove these two lines.

The following line just starts to wait for the user to press `Pass` or `Fail`.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 86:

> 84:         PassFailJFrame.positionTestWindow(frame, PassFailJFrame.Position.HORIZONTAL);
> 85: 
> 86:         frame.setPreferredSize(new Dimension(600, 600));

You use `pack` below, so it seems redundant.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 95:

> 93:             public void propertyChange(PropertyChangeEvent evt) {
> 94:                 if (JFileChooser.SELECTED_FILE_CHANGED_PROPERTY.equals(evt.getPropertyName())) {
> 95:                     System.out.println(String.format("Absolute Path : %s",evt.getNewValue()));

When with jtreg, the output to the console is not seen.

You have to provide a UI where these lines would be added.

The usage of `format` for such a simple case could be replaced by string concatenation using `+`.

In addition to that, you may keep track whether a `null` value is seen or not. No `null` value is expected. If it's seen, it's a failure.

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.org  Wed Aug  3 13:25:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 3 Aug 2022 13:25:27 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v2]
In-Reply-To: <VrCGDZiU3LnQwGS3XQ9zmZ4w-GjgOI3duZJtqcXtllM=.b668c8f3-4172-4438-a138-c5a0b20bc9ee@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <N0aSqPyUYe6_EORrKOnWLadI2Scqz1iFq-skz-XFExQ=.abfc76cf-8b5c-41a5-98ae-633d401282e3@github.com>
 <VrCGDZiU3LnQwGS3XQ9zmZ4w-GjgOI3duZJtqcXtllM=.b668c8f3-4172-4438-a138-c5a0b20bc9ee@github.com>
Message-ID: <dcSE3Mn8CwT7eB_1FQy8yPMcn9H3q83OybcbBf_kRqA=.89ff31b4-abfa-447e-9ed7-a8f41816a018@github.com>

On Wed, 3 Aug 2022 07:55:33 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 76:
>> 
>>> 74:                 2. Create a Symbolic link targeting the created test directory.
>>> 75:                     ex : mklink /D c:\\link c:\\target
>>> 76:                 3. In JFileChooser, navigate to "link" created directed.
>> 
>> ?navigate to directory where you created the link. In this example, to C:\ drive.
>> 
>> Please use the capital C: for the drive.
>
> Updated.

I can't see it updated.

In fact I suggest providing a script.


1. Open an elevated Command Prompt.
2. Paste the following commands:

cd /d C:\
mkdir filechooser
cd filechooser
mkdir target
mklink /d link target

3. Navigate to C:\filechooser in the JFileChooser.
4. ...
5. When done with testing, paste the following commands to remove the 'filechooser' directory

cd \
rmdir /s /q filechooser

or use File Explorer to clean it up.

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

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


From tr at openjdk.org  Wed Aug  3 14:04:34 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Aug 2022 14:04:34 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v3]
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <7XjeOPIZVcuyTn2Cj_K3xFpPVu60O8lTZFL2wzrQoqk=.f4042307-c580-4760-8578-9b25956a3369@github.com>

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

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

 - Added Dialog information for printing Absolute path
 - Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9597/files
  - new: https://git.openjdk.org/jdk/pull/9597/files/0406d504..985a7e75

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

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

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


From aivanov at openjdk.org  Wed Aug  3 15:17:56 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 3 Aug 2022 15:17:56 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v3]
In-Reply-To: <7XjeOPIZVcuyTn2Cj_K3xFpPVu60O8lTZFL2wzrQoqk=.f4042307-c580-4760-8578-9b25956a3369@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <7XjeOPIZVcuyTn2Cj_K3xFpPVu60O8lTZFL2wzrQoqk=.f4042307-c580-4760-8578-9b25956a3369@github.com>
Message-ID: <RVdzvXnBFPDJsqNz95kcHtI-ZOwPg-EiiAmkyZ_l0GY=.bec19f2d-2392-4791-b4f3-2456f7ebc388@github.com>

On Wed, 3 Aug 2022 14:04:34 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Added Dialog information for printing Absolute path
>  - Updated based on review comments

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 37:

> 35: 
> 36: /** @test
> 37:   * @bug 8281966

Suggestion:

/*
 * @test
 * @bug 8281966


It is not a javadoc comment, only one asterisk should be used. Please align the following lines by removing one space.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 45:

> 43:   * @run main/manual FileChooserSymLinkTest
> 44: */
> 45: 

I'd rather remove this blank line so that the comment above is attached to the class declaration.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 80:

> 78:                 4. On click of the "link" directory, if the Absolute path of
> 79:                     Symbolic Link is valid then Click PASS, else if it is
> 80:                     null then Click FAIL.(Including MultiSelection Mode SET)

Is this possible? Your test does not allow for multi-selection mode.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 99:

> 97:                     JOptionPane.showMessageDialog(null, evt.getNewValue(),
> 98:                             "Absolute path",
> 99:                             JOptionPane.INFORMATION_MESSAGE);

I don't think it is a good idea. For each selection, the tester will get a modal dialog box with the path. It could even prevent the tester from navigating directories for testing.

I suggest adding a `JListBox` or `JTextArea` on top or bottom of the `JFileChooser` and add the messages there.

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

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


From tr at openjdk.org  Wed Aug  3 15:54:44 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Aug 2022 15:54:44 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v2]
In-Reply-To: <Tw_JV5wMS8XBi16aNn5BKCHEDXAHpAf9_3-RIW6MQQY=.8039ccbe-375d-4f4d-a74b-6439d344e187@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <YTO50XW2bmeme1SzMkQCvVciS-wELjEc5CDWATtiBwE=.c855c1fe-299c-44d7-9551-5aac3a861a60@github.com>
 <Tw_JV5wMS8XBi16aNn5BKCHEDXAHpAf9_3-RIW6MQQY=.8039ccbe-375d-4f4d-a74b-6439d344e187@github.com>
Message-ID: <7iKrrIQPSBVDD_hVR5XunSHq5n4fYUzvWUS1lFAr_uc=.b2f3f248-83e5-4f21-a9f7-a3638a6e869e@github.com>

On Wed, 3 Aug 2022 13:10:15 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix : Updated to handle multiSelection case
>>  - Manual Test Indicator Added in JTREG tag
>
> test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 64:
> 
>> 62: 
>> 63:         robot.delay(2000);
>> 64:         robot.waitForIdle();
> 
> Robot is not required. You can safely remove these two lines.
> 
> The following line just starts to wait for the user to press `Pass` or `Fail`.

> It does not work.
> 
> In the single-selection case, I see the following output:
> 
> ```
> Absolute Path : null
> Absolute Path : C:\filechooser\link
> ```
> 
> Above, `null` corresponds to `C:\filechooser\target` folder which is the target of the `link`.
> 
> Neither does it work in the multi-selection case:
> 
> ```
> Absolute Path : C:\filechooser
> Absolute Path : null
> Absolute Path : C:\filechooser\target
> ```
> 
> But now it doesn't work in a different way: `link` is reported as `null`.
> 
> I can't see none of the comments addressed in the test even though you explicitly added comments that you updated the code. A missing push?

Yeah, sorry for that, I had missed to push the updates.

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

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


From tr at openjdk.org  Wed Aug  3 15:54:45 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Aug 2022 15:54:45 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v2]
In-Reply-To: <7iKrrIQPSBVDD_hVR5XunSHq5n4fYUzvWUS1lFAr_uc=.b2f3f248-83e5-4f21-a9f7-a3638a6e869e@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <YTO50XW2bmeme1SzMkQCvVciS-wELjEc5CDWATtiBwE=.c855c1fe-299c-44d7-9551-5aac3a861a60@github.com>
 <Tw_JV5wMS8XBi16aNn5BKCHEDXAHpAf9_3-RIW6MQQY=.8039ccbe-375d-4f4d-a74b-6439d344e187@github.com>
 <7iKrrIQPSBVDD_hVR5XunSHq5n4fYUzvWUS1lFAr_uc=.b2f3f248-83e5-4f21-a9f7-a3638a6e869e@github.com>
Message-ID: <NzNmsTtv9KNy2rSn8aINNIOCu87cH9ZvbGregFIGAm8=.84739171-dde3-4861-9ba8-ee34dfab43ea@github.com>

On Wed, 3 Aug 2022 15:47:25 GMT, Tejesh R <tr at openjdk.org> wrote:

> > It does not work.
> > In the single-selection case, I see the following output:
> > ```
> > Absolute Path : null
> > Absolute Path : C:\filechooser\link
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > Above, `null` corresponds to `C:\filechooser\target` folder which is the target of the `link`.
> > Neither does it work in the multi-selection case:
> > ```
> > Absolute Path : C:\filechooser
> > Absolute Path : null
> > Absolute Path : C:\filechooser\target
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > But now it doesn't work in a different way: `link` is reported as `null`.
> > I can't see none of the comments addressed in the test even though you explicitly added comments that you updated the code. A missing push?
> 
> Yeah, sorry for that, I had missed to push the updates.

For link it doesn't work, I have updated only for symbolic links and not for .lnk. .lnk logic is retained as it is.

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

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


From tr at openjdk.org  Wed Aug  3 16:03:44 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Aug 2022 16:03:44 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v3]
In-Reply-To: <RVdzvXnBFPDJsqNz95kcHtI-ZOwPg-EiiAmkyZ_l0GY=.bec19f2d-2392-4791-b4f3-2456f7ebc388@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <7XjeOPIZVcuyTn2Cj_K3xFpPVu60O8lTZFL2wzrQoqk=.f4042307-c580-4760-8578-9b25956a3369@github.com>
 <RVdzvXnBFPDJsqNz95kcHtI-ZOwPg-EiiAmkyZ_l0GY=.bec19f2d-2392-4791-b4f3-2456f7ebc388@github.com>
Message-ID: <ge0TbmpPgTcemaUUMnzTHFdLL3gh1TMZft5RFpXpdX8=.64822769-c534-4447-b721-b8e989278143@github.com>

On Wed, 3 Aug 2022 15:11:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Added Dialog information for printing Absolute path
>>  - Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 80:
> 
>> 78:                 4. On click of the "link" directory, if the Absolute path of
>> 79:                     Symbolic Link is valid then Click PASS, else if it is
>> 80:                     null then Click FAIL.(Including MultiSelection Mode SET)
> 
> Is this possible? Your test does not allow for multi-selection mode.

Should I enable multiselection in code?

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

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


From tr at openjdk.org  Wed Aug  3 17:08:05 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Aug 2022 17:08:05 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v3]
In-Reply-To: <RVdzvXnBFPDJsqNz95kcHtI-ZOwPg-EiiAmkyZ_l0GY=.bec19f2d-2392-4791-b4f3-2456f7ebc388@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <7XjeOPIZVcuyTn2Cj_K3xFpPVu60O8lTZFL2wzrQoqk=.f4042307-c580-4760-8578-9b25956a3369@github.com>
 <RVdzvXnBFPDJsqNz95kcHtI-ZOwPg-EiiAmkyZ_l0GY=.bec19f2d-2392-4791-b4f3-2456f7ebc388@github.com>
Message-ID: <z-30dNT1SP1rupt29ajJ0aOHJ4dSJWBG9Si5RvJm7Zc=.412cbcd7-da5c-4240-aeae-1c4f7bb437b9@github.com>

On Wed, 3 Aug 2022 15:14:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Added Dialog information for printing Absolute path
>>  - Updated based on review comments
>
> test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 99:
> 
>> 97:                     JOptionPane.showMessageDialog(null, evt.getNewValue(),
>> 98:                             "Absolute path",
>> 99:                             JOptionPane.INFORMATION_MESSAGE);
> 
> I don't think it is a good idea. For each selection, the tester will get a modal dialog box with the path. It could even prevent the tester from navigating directories for testing.
> 
> I suggest adding a `JListBox` or `JTextArea` on top or bottom of the `JFileChooser` and add the messages there.

Can use JLabel and keep updating(remove the old value and show path which is clicked) it right......? Storing previous paths are not required anyhow.

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

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


From sspitsyn at openjdk.org  Wed Aug  3 17:34:22 2022
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 3 Aug 2022 17:34:22 GMT
Subject: RFR: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations" [v5]
In-Reply-To: <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
 <iGzf4bS94gxu-1softdYXsv4nW_K6l0dhEDhx9oYrS0=.a69eb0c4-ea8c-493b-bfbe-0bcd0781ecac@github.com>
Message-ID: <feOKmPYl5W1JQLFVLPQrblg18RKtcs6QQ4eEfPmCg4A=.8d1b1f89-14dc-45ac-acbb-58a3736faf51@github.com>

On Wed, 3 Aug 2022 02:34:48 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
>> 
>> The issue could be reproduced by zero.
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update tags order

Marked as reviewed by sspitsyn (Reviewer).

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

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


From aoqi at openjdk.org  Wed Aug  3 17:36:14 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Wed, 3 Aug 2022 17:36:14 GMT
Subject: Integrated: 8291508: Fix some tests with
 "requires vm.jvmti & vm.continuations"
In-Reply-To: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
References: <IuBdRyzDGhfyKIpFi_JFsYZmlpa5my4n594Q1s46gow=.faada2f5-d00c-433a-9e38-b6057ee72671@github.com>
Message-ID: <shaZMSKrDCJTmFW5jYfs8ZWjLRlPvb8DEAaZdfR6IQI=.59c352ff-dcc9-4012-b044-b2513021cd3c@github.com>

On Thu, 28 Jul 2022 16:11:12 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> `vmTestbase/nsk/jvmti/GetThreadInfo/thrinfo001/TestDescription.java` and `vmTestbase/nsk/jvmti/RedefineClasses/StressRedefineVirtual/StressRedefineVirtual.java` are added or modified by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161), and they are failed if Loom or JVMTI is not supported.
> 
> The issue could be reproduced by zero.

This pull request has now been integrated.

Changeset: 0cc49fd9
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Serguei Spitsyn <sspitsyn at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cc49fd9eac5259543a3c41b7a32b6e01a1b0ad5
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8291508: Fix some tests with "requires vm.jvmti & vm.continuations"

Reviewed-by: sspitsyn, lmesnik, alanb

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

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


From honkar at openjdk.org  Wed Aug  3 19:58:57 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 3 Aug 2022 19:58:57 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
Message-ID: <DEoZ12EPT4N_XbRC30G7TnvH3ADew_Q_X99A8-xzC0I=.e9296afe-5af2-41ca-86a2-cd920e9f58a1@github.com>

On Fri, 29 Jul 2022 22:01:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added screen insets to account for taskbar position, doc changes
>
> Well .. there surely must be test scenarios where a Frame is required. Perhaps the test moves it, iconifies, needs
> a specific size .. expects focus to move in a certain order between components in the frame .. wants to use
> heavyweight AWT components .. .in some of these I expect the extra instruction part doesn't matter but you only have to find ONE case where it matters .. then there's the fact you'd have to rewrite all the existing tests. And why a JSplitPane, anyway ? Odd choice. 
> 
> I can imagine that it might be interesting to add a new version that works with a JPanel as the container for the test and let a test author decide if they want to use that for future tests.

After evaluating possible alternative solutions as well as suggestions provided by @prrace & @aivanov-jdk, I think introducing small delay (Thread.sleep) would be the best option - for syncing the updated position to window manager and keeping in mind the broader range of testing requirement that the framework needs to support for now.

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

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


From duke at openjdk.org  Thu Aug  4 06:07:05 2022
From: duke at openjdk.org (duke)
Date: Thu, 4 Aug 2022 06:07:05 GMT
Subject: Withdrawn: 8285149: Using HashMap.newHashMap to replace new
 HashMap(int)
In-Reply-To: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
References: <nbTEkGMOp3gIZCYq1vfhE1Zy1RDJsWFkUGQzVPM4gI0=.427e4dba-2ea2-48e5-9cdd-e3eade99096c@github.com>
Message-ID: <6zyYs300tD4dVrr_FT6ILURyaxkXaKtDe3rbLm1rMD8=.64484460-e180-4b3b-97f9-8573daa11da0@github.com>

On Tue, 19 Apr 2022 17:44:10 GMT, XenoAmess <duke at openjdk.org> wrote:

> These are the changes that too many to be reviewed in 8186958, thus split some of them out.

This pull request has been closed without being integrated.

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

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


From dnguyen at openjdk.org  Thu Aug  4 06:12:52 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 4 Aug 2022 06:12:52 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide previously
 visible tab component [v2]
In-Reply-To: <VDP6V8PuELQ3JqT5pHV3aa0VdBayUlF5wMcrJJMYQSk=.a09ad2c2-4552-4c26-905d-6ba93e00a27b@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
 <VDP6V8PuELQ3JqT5pHV3aa0VdBayUlF5wMcrJJMYQSk=.a09ad2c2-4552-4c26-905d-6ba93e00a27b@github.com>
Message-ID: <O723SmMMRGC2HcR_NODYxsdc0vRWygIeGrmVMQ03_os=.99dbb669-bdac-4e90-a944-6ff2155f85fc@github.com>

On Sat, 30 Jul 2022 00:28:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> A simple change listener is used in JTabbedPane to lazily fill with components - this is done by adding the components to JTabbedPane using the `setComponentAt` in the change listener.
>> 
>> Previously, if the change listener was placed before calling `addTab()` , the previous visible component was overlapping with the current visible component. To fix it, the visibility of previous component is set to false before the current component's visibility is set to true in `setComponentAt`.
>> 
>> Following are the before and after fix screenshots-
>> 
>> ![image](https://user-images.githubusercontent.com/95945681/181658303-ff3a7df7-5af6-4e76-a103-45d4d76480c3.png)
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug id changed, added isVisible check

Applied the change and ran your test. The test clearly shows the difference, and it looks good to me.

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

Marked as reviewed by dnguyen (Author).

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


From dnguyen at openjdk.org  Thu Aug  4 06:12:53 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 4 Aug 2022 06:12:53 GMT
Subject: RFR: 8259687: JTabbedPane.setComponentAt doesn't hide previously
 visible tab component [v2]
In-Reply-To: <yf_1j9UzSJJkIsIk9WBnskCrIkaI1GDqkS6b6EFJHa4=.18fcd975-89a8-432d-90b2-7f3e8522174b@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
 <cHU2mKahjQKn5zHRk91Z4RTYuj4a-GsiR1-LY37hA6w=.e98f537d-f42f-450c-8f34-a41c4e5d9902@github.com>
 <yElNBRXFSX1iOiSD-kGyYgGGl2zaDV8cLC_OHO9W8Ug=.96604f59-2f41-4b0d-82c9-a9089f5d5b3c@github.com>
 <yf_1j9UzSJJkIsIk9WBnskCrIkaI1GDqkS6b6EFJHa4=.18fcd975-89a8-432d-90b2-7f3e8522174b@github.com>
Message-ID: <0wCb4Jw8Lq77B93FhKjmXuxfXOoAr76ai65GVw9eU1s=.17719ba0-3004-47da-a48c-5f5d6f7a7c92@github.com>

On Tue, 2 Aug 2022 06:49:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I thought it might be redundant since the setVisible() checks for visibility of component within show() and hide(). But to add clarity I have add `isVisible` check.
>
> It seems this check is followed in this class
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L390
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/JTabbedPane.java#L419

I agree. The isVisible check is used for similar purposes so it's for the best to follow convention here and use it.

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

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


From duke at openjdk.org  Thu Aug  4 06:53:01 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Aug 2022 06:53:01 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
Message-ID: <moO1qkFQEwP-RLT3VE9jEDFVtsxvnudTSEZ-ZB5bZbc=.9d0a2ce7-c5f2-4d06-9b92-e215bf200e57@github.com>

On Thu, 28 Jul 2022 10:08:24 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   creating and deleting test files dynamically

Attached the screenshot for filesize in native Oracle linux and JFileChooser. 

![Oracle_Linux](https://user-images.githubusercontent.com/107542245/182781140-92ccfa3a-3c3f-4827-9696-a72e14b27835.png)
![JFileChooser_Oracle_Linux](https://user-images.githubusercontent.com/107542245/182781147-79b832d3-00b1-414b-bc40-7ed028cf65ce.png)

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

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


From duke at openjdk.org  Thu Aug  4 08:38:03 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 4 Aug 2022 08:38:03 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v12]
In-Reply-To: <ahtRDQzU0edS6VY9zB7m9EJBNqKZheUSeXbpN5EqCdM=.0dd5c410-e292-4aa5-a1f7-7a7cb21ac584@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <-jB87It9Ls537Um6y9hcTwz5OE-WVa-zgsbfCL7GG38=.6cc5e3f3-602f-4fdc-8196-df506c9c0b3a@github.com>
 <ahtRDQzU0edS6VY9zB7m9EJBNqKZheUSeXbpN5EqCdM=.0dd5c410-e292-4aa5-a1f7-7a7cb21ac584@github.com>
Message-ID: <S1xJ4UzO-hik8Mjvs2ySt24Rj--byecJGXFa0rix2vo=.e9ca0429-b36a-4401-acd4-2d13a425f053@github.com>

On Wed, 3 Aug 2022 09:48:58 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix rotated text metrics
>
> src/java.desktop/macosx/classes/sun/font/CCompositeGlyphMapper.java line 67:
> 
>> 65:     protected int convertToGlyph(int unicode) {
>> 66:         int glyph = convertToGlyph(unicode, 0);
>> 67: //        setCachedGlyphCode(unicode, glyph);
> 
> What's the purpose of the commented line?

Committed this accidentally, should have deleted this line

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

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


From duke at openjdk.org  Thu Aug  4 08:43:00 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Thu, 4 Aug 2022 08:43:00 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v12]
In-Reply-To: <ahtRDQzU0edS6VY9zB7m9EJBNqKZheUSeXbpN5EqCdM=.0dd5c410-e292-4aa5-a1f7-7a7cb21ac584@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
 <-jB87It9Ls537Um6y9hcTwz5OE-WVa-zgsbfCL7GG38=.6cc5e3f3-602f-4fdc-8196-df506c9c0b3a@github.com>
 <ahtRDQzU0edS6VY9zB7m9EJBNqKZheUSeXbpN5EqCdM=.0dd5c410-e292-4aa5-a1f7-7a7cb21ac584@github.com>
Message-ID: <5_Z7dcr8Ux6fWSu6FzaKyW7HhaeBF2NY9MxUilTw4W8=.4d358a8b-50fa-47c3-844d-8f8bbb7e967e@github.com>

On Wed, 3 Aug 2022 09:51:22 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Nikita Gubarkov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix rotated text metrics
>
> src/java.desktop/share/classes/sun/font/StandardGlyphVector.java line 1835:
> 
>> 1833: 
>> 1834:         void appendGlyphRenderData(int glyphID, GlyphRenderData result, float x, float y) {
>> 1835:             // !!! fontStrike needs a method for this.  For that matter, GeneralPath does.
> 
> It's better to use well known "TODO" here

That was just copied from `appendGlyphOutline` above :)

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

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


From psadhukhan at openjdk.org  Thu Aug  4 09:18:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Aug 2022 09:18:28 GMT
Subject: Integrated: 4890041: Remove TAB and Shift TAB from Popup Menu in Motif
 Look & Feel
In-Reply-To: <oK56WIxPa5Noats9OoeUbSpR3jQrzYbcRP8wSXxfvvw=.3446f125-e6a5-48a7-bfe0-4bf68999943d@github.com>
References: <oK56WIxPa5Noats9OoeUbSpR3jQrzYbcRP8wSXxfvvw=.3446f125-e6a5-48a7-bfe0-4bf68999943d@github.com>
Message-ID: <9G8rwnjjnSO6gxWere6sG_PBl6spAQ-AZrq6dU5IS_8=.e2eff679-692b-4aa5-9fcb-8a06beb14353@github.com>

On Fri, 22 Jul 2022 09:23:41 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> This is a cleanup of unneeded TAB and Shift TAB keybindings for PopupMenu.selectedWindowInputMapBindings which is consistent with other L&Fs as can be seen here
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1131
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthLookAndFeel.java#L702
> 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java#L806
> 
> No regression test added for this code cleanup

This pull request has now been integrated.

Changeset: 26e5c112
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/26e5c112daa30697a42047e78744c1c533611e10
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

4890041: Remove TAB and Shift TAB from Popup Menu in Motif Look & Feel

Reviewed-by: azvegint, prr

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

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


From tr at openjdk.org  Thu Aug  4 12:08:16 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Aug 2022 12:08:16 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v3]
In-Reply-To: <RVdzvXnBFPDJsqNz95kcHtI-ZOwPg-EiiAmkyZ_l0GY=.bec19f2d-2392-4791-b4f3-2456f7ebc388@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <7XjeOPIZVcuyTn2Cj_K3xFpPVu60O8lTZFL2wzrQoqk=.f4042307-c580-4760-8578-9b25956a3369@github.com>
 <RVdzvXnBFPDJsqNz95kcHtI-ZOwPg-EiiAmkyZ_l0GY=.bec19f2d-2392-4791-b4f3-2456f7ebc388@github.com>
Message-ID: <Eh9tzjn8tio7zZQuxAdQmxaaPKqSskE0t9nJZoqpOfk=.c981af3a-9be4-4ace-af6d-63089822fbcf@github.com>

On Wed, 3 Aug 2022 15:14:22 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Added Dialog information for printing Absolute path
>>  - Updated based on review comments
>
> Changes requested by aivanov (Reviewer).

@aivanov-jdk I have handled the multi selection case and updated the test case to handle both single and multi selection. Please let me know if these are fine.

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

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


From tr at openjdk.org  Thu Aug  4 12:08:15 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Aug 2022 12:08:15 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v4]
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <hPHPXL1u7geBSLDfz907LfNmHPfVOZfr59gHa8PkE9k=.eb99362d-3283-43ce-a30b-0e035a9e56d6@github.com>

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

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

  Fix for multi selection and updated the test to handle both single and multi selection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9597/files
  - new: https://git.openjdk.org/jdk/pull/9597/files/985a7e75..dc315aa1

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

  Stats: 87 lines in 2 files changed: 50 ins; 11 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/9597.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9597/head:pull/9597

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


From aivanov at openjdk.org  Thu Aug  4 15:39:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 4 Aug 2022 15:39:19 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v4]
In-Reply-To: <hPHPXL1u7geBSLDfz907LfNmHPfVOZfr59gHa8PkE9k=.eb99362d-3283-43ce-a30b-0e035a9e56d6@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <hPHPXL1u7geBSLDfz907LfNmHPfVOZfr59gHa8PkE9k=.eb99362d-3283-43ce-a30b-0e035a9e56d6@github.com>
Message-ID: <IFVHEPGMwaCQ7aOQ3k51t2BiIlp6BhfVDl-9J9Y0nzs=.36e1af0e-2290-448e-84ec-4769db151ea2@github.com>

On Thu, 4 Aug 2022 12:08:15 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for multi selection and updated the test to handle both single and multi selection

It works fine now. Thank you!

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 713:

> 711:                             && chooser.isTraversable(((File)objects[0]))
> 712:                             && (useSetDirectory || (!fsv.isFileSystem(((File)objects[0]))
> 713:                             && !Files.isSymbolicLink(Paths.get(((File)objects[0]).getPath()))))) {

~~This does not align with other parts of the code where `isSymbolicLink` is combined together with `isFileSystem`.~~

You should format the code to avoid confusion: `isSymbolicLink` is not part of the top-level condition but rather of the part inside the parentheses after `||`

This should look this way:


                            && (useSetDirectory
                                || (!fsv.isFileSystem(((File)objects[0]))
                                    && !Files.isSymbolicLink(((File)objects[0]).toPath())))) {

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 721:

> 719:                                 File f = (File) object;
> 720:                                 boolean isDir = f.isDirectory();
> 721:                                 Path path = Paths.get(f.getPath());

Suggestion:

                                Path path = f.toPath();


You can directly convert a `File` to `Path`. Please update this in all the places.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 41:

> 39: 
> 40: /*
> 41:  *@test

Suggestion:

 * @test


A space has disappeared.

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

> 56:     static JTextArea textArea = null;
> 57:     static JCheckBox checkMSelection = null;
> 58:     static PassFailJFrame passFailJFrame = null;

There's no need to assign `null` or `false` explicitly, these are the default values for reference types.

Why do you use `Boolean` type? Can't it be primitive `boolean` type instead?

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 79:

> 77:                 1. Open an elevated Command Prompt.
> 78:                 2. Paste the following commands:
> 79:                 cd /d C:\

Suggestion:

                cd /d C:\\


Another backslash is missing to display the backslash.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 83:

> 81:                 cd FileChooserTest
> 82:                 mkdir target
> 83:                 mklink /d link FileChooserTest

The command should create a symbolic to the target:


mklink /d link target

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 95:

> 93:                    with valid Absolute path then Click PASS, else either
> 94:                    of them failed click FAIL.
> 95:                 6. When done with testing, paste the following commands to remove the 'filechooser' directory

I propose the following text:


                5. Single-selection:
                   Click "link" directory, the absolute path of the symbolic
                   link should be displayed. If it's null, click FAIL.
                   Click "target" directory, its absolute path should be
                   displayed.
                    
                   Enable multiple selection by clicking the checkbox.
                   Multi-selection:
                   Click "link", press Ctrl and then click "target".
                   Both should be selected and their absolute paths should be
                   displayed.
                   
                   If "link" can't be selected or if its absolute path is null,
                   click FAIL.
                   
                   If "link" can be selected in both single- and multi-selection modes,
                   click PASS.
                6. When done with testing, paste the following commands to remove
                   the 'FileChooserTest' directory:


I hope the instructions for testing in 5 are clearer now.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 97:

> 95:                 6. When done with testing, paste the following commands to remove the 'filechooser' directory
> 96:                 cd \
> 97:                 rmdir /s /q filechooser

Suggestion:

                cd \\
                rmdir /s /q C:\\FileChooserTest


Another backslash is missing in the first line to correctly display `` and you didn't update the directory name for `rmdir`.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 103:

> 101:         frame = new JFrame("JFileChooser Symbolic Link test");
> 102:         panel = new JPanel(new BorderLayout());
> 103:         checkMSelection = new JCheckBox("Enable Multi-Selection");

`checkMSelection` ? `multiSelection`?

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 104:

> 102:         panel = new JPanel(new BorderLayout());
> 103:         checkMSelection = new JCheckBox("Enable Multi-Selection");
> 104:         textArea = new JTextArea();

`textArea` ? `pathList`?

I also suggest passing rows, columns to define the preferred size: `new JTextArea(10, 50);`.

Then remove the line: `textArea.setPreferredSize(new Dimension(600,300));`. The UI fits better on the screen this way.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 105:

> 103:         checkMSelection = new JCheckBox("Enable Multi-Selection");
> 104:         textArea = new JTextArea();
> 105:         jfc = new JFileChooser();

Suggestion:

        jfc = new JFileChooser(new File("C:\"));


To start file chooser at the root of drive `C:` where the sample commands create the `FileChooserTest` folder.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 106:

> 104:         textArea = new JTextArea();
> 105:         jfc = new JFileChooser();
> 106:         passFailJFrame = new PassFailJFrame(INSTRUCTIONS);

Suggestion:

        passFailJFrame = new PassFailJFrame("Test Instructions",
                                            INSTRUCTIONS,
                                            5L,
                                            35, 40);


Since the instructions are long for this test, I suggest passing additional parameters and modifying the default number of rows displayed so that the complete instructions are displayed.

If you change the instruction text, you may need to amend the number of rows (35).

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 112:

> 110:         frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
> 111:         panel.add(checkMSelection,BorderLayout.EAST);
> 112:         panel.add(textArea,BorderLayout.WEST);

Spaces after comma.

Wrap the `textArea` into `JScrollPane`:


panel.add(new JScrollPane(textArea), BorderLayout.WEST);


Thus text could be scrolled.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 116:

> 114:         jfc.setControlButtonsAreShown(false);
> 115:         jfc.setFileSelectionMode(JFileChooser.DIRECTORIES_ONLY);
> 116:         jfc.setMultiSelectionEnabled(bMultiSel_Enabled);

Suggestion:

        jfc.setMultiSelectionEnabled(checkMSelection.isSelected());


To drop `bMultiSel_Enabled` field.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 118:

> 116:         jfc.setMultiSelectionEnabled(bMultiSel_Enabled);
> 117:         textArea.setPreferredSize(new Dimension(600,300));
> 118:         textArea.append("Path List");

Suggestion:

        textArea.append("Path List\n");


Add a line break right away. To simplify appending the lines in property changed listener.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 128:

> 126:                 } else {
> 127:                     bMultiSel_Enabled = false;
> 128:                 }

Suggestion:

                bMultiSel_Enabled = ((JCheckBox)source).isSelected();


In fact, you don't need `bMultiSel_Enabled` field. Just use `isSelected()` directly:


jfc.setMultiSelectionEnabled(((JCheckBox)source).isSelected());


If you like, you can access the `JCheckBox` instance directly, you saved it in a field:


jfc.setMultiSelectionEnabled(checkMSelection.isSelected());

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 136:

> 134:                 if (JFileChooser.SELECTED_FILE_CHANGED_PROPERTY.equals(evt.getPropertyName())) {
> 135:                     System.out.println("Absolute Path : "+evt.getNewValue());
> 136:                     textArea.append("\nAbsolute Path : "+evt.getNewValue());

Spaces around `+`.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 137:

> 135:                     System.out.println("Absolute Path : "+evt.getNewValue());
> 136:                     textArea.append("\nAbsolute Path : "+evt.getNewValue());
> 137:                 }

I suggest handling `SELECTED_FILES_CHANGED_PROPERTY` to ensure multi-selection works correctly:


            @Override
            public void propertyChange(PropertyChangeEvent evt) {
                String msg = null;
                if (JFileChooser.SELECTED_FILE_CHANGED_PROPERTY.equals(evt.getPropertyName())) {
                    msg = "Absolute Path : " + evt.getNewValue();
                } else if (JFileChooser.SELECTED_FILES_CHANGED_PROPERTY.equals(evt.getPropertyName())) {
                    msg = "Selected files: " + Arrays.toString((File[]) evt.getNewValue());
                }

                if (msg != null) {
                    System.out.println(msg);
                    textArea.append(msg + "\n");
                }
            }

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 141:

> 139:         });
> 140:         frame.add(panel,BorderLayout.NORTH);
> 141:         frame.add(jfc,BorderLayout.CENTER);

Spaces after comma.

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

Changes requested by aivanov (Reviewer).

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


From aivanov at openjdk.org  Thu Aug  4 15:39:21 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 4 Aug 2022 15:39:21 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v2]
In-Reply-To: <NzNmsTtv9KNy2rSn8aINNIOCu87cH9ZvbGregFIGAm8=.84739171-dde3-4861-9ba8-ee34dfab43ea@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <YTO50XW2bmeme1SzMkQCvVciS-wELjEc5CDWATtiBwE=.c855c1fe-299c-44d7-9551-5aac3a861a60@github.com>
 <Tw_JV5wMS8XBi16aNn5BKCHEDXAHpAf9_3-RIW6MQQY=.8039ccbe-375d-4f4d-a74b-6439d344e187@github.com>
 <7iKrrIQPSBVDD_hVR5XunSHq5n4fYUzvWUS1lFAr_uc=.b2f3f248-83e5-4f21-a9f7-a3638a6e869e@github.com>
 <NzNmsTtv9KNy2rSn8aINNIOCu87cH9ZvbGregFIGAm8=.84739171-dde3-4861-9ba8-ee34dfab43ea@github.com>
Message-ID: <0WiDa7XxpqAUPaI1oFzpSoECO9-8j9T77WcFQxpjuU0=.6cc92fb4-e0a8-4a91-9695-b6a9e2990196@github.com>

On Wed, 3 Aug 2022 15:50:37 GMT, Tejesh R <tr at openjdk.org> wrote:

> In the single-selection case, I see the following output:
> 
> ```
> Absolute Path : null
> Absolute Path : C:\filechooser\link
> ```

Sorry about that. Upon re-testing, this scenario worked fine with your original changes.

> For link it doesn't work, I have updated only for symbolic links and not for .lnk. .lnk logic is retained as it is.

I didn't test `.lnk` files, I tested with symbolic links created using `mklink` command.

Your changes worked in single-selection case. Sorry, I must have done something wrong.

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

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


From tr at openjdk.org  Thu Aug  4 18:45:23 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Aug 2022 18:45:23 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v4]
In-Reply-To: <IFVHEPGMwaCQ7aOQ3k51t2BiIlp6BhfVDl-9J9Y0nzs=.36e1af0e-2290-448e-84ec-4769db151ea2@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <hPHPXL1u7geBSLDfz907LfNmHPfVOZfr59gHa8PkE9k=.eb99362d-3283-43ce-a30b-0e035a9e56d6@github.com>
 <IFVHEPGMwaCQ7aOQ3k51t2BiIlp6BhfVDl-9J9Y0nzs=.36e1af0e-2290-448e-84ec-4769db151ea2@github.com>
Message-ID: <b0f1eY_eGuPh1l7vOQNVnflHa6BIdOJ6x7eEV884NhM=.06d23183-86d4-43a2-afb9-2add8067c972@github.com>

On Thu, 4 Aug 2022 15:32:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix for multi selection and updated the test to handle both single and multi selection
>
> It works fine now. Thank you!

@aivanov-jdk Updated all the review comments.

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

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


From tr at openjdk.org  Thu Aug  4 18:45:21 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Aug 2022 18:45:21 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v5]
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <zc7his_JsVFspd0X7RYBtTTUMkbmBENPEpxAKQHbezc=.abec7553-2b60-41b8-aff9-4b7c623ba01c@github.com>

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9597/files
  - new: https://git.openjdk.org/jdk/pull/9597/files/dc315aa1..2bfb588b

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

  Stats: 65 lines in 2 files changed: 22 ins; 7 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/9597.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9597/head:pull/9597

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


From aivanov at openjdk.org  Thu Aug  4 18:56:00 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 4 Aug 2022 18:56:00 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v5]
In-Reply-To: <zc7his_JsVFspd0X7RYBtTTUMkbmBENPEpxAKQHbezc=.abec7553-2b60-41b8-aff9-4b7c623ba01c@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <zc7his_JsVFspd0X7RYBtTTUMkbmBENPEpxAKQHbezc=.abec7553-2b60-41b8-aff9-4b7c623ba01c@github.com>
Message-ID: <AiNiTqBW6mQ6xNdgGX4QlfAqUczpl6JVuDIHFx9lFJI=.a8d5d13c-3aae-4441-ac0a-48044c18b9d7@github.com>

On Thu, 4 Aug 2022 18:45:21 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 720:

> 718:                             ArrayList<File> fList = new ArrayList<File>(objects.length);
> 719:                             for (Object object : objects) {
> 720:                                 File f = (File) object;

I'd be grateful if you update this line even though it's not part of your changes:

Suggestion:

                                File f = (File)object;


It's to make casts consistent. Only this cast has a space before the argument in the entire method.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 748:

> 746:                         if (usesSingleFilePane) {
> 747:                             Path path = Paths.get(file.getPath());
> 748:                             if (Files.isSymbolicLink(path)) {

Suggestion:

                            if (Files.isSymbolicLink(file.toPath())) {


One more instance of `Paths.get` should be replaced with `file.toPath()`.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 119:

> 117:         pathList = new JTextArea(10,50);
> 118:         jfc = new JFileChooser(new File("C:\\"));
> 119:         passFailJFrame = new PassFailJFrame("Test Instructions",INSTRUCTIONS,5L,35,40);

There should be a space after the comma in parameter list.

test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java line 125:

> 123:         frame.setDefaultCloseOperation(WindowConstants.EXIT_ON_CLOSE);
> 124:         panel.add(multiSelection,BorderLayout.EAST);
> 125:         panel.add(new JScrollPane(pathList),BorderLayout.WEST);

Space after comma.

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

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


From prr at openjdk.org  Thu Aug  4 20:23:40 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Aug 2022 20:23:40 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
Message-ID: <Qd0bID57SxLxZtpy82HoxeP1CCfyUEbOvHJMVOPSaew=.a1096c7c-e315-4ded-9edc-0f75aa57d7aa@github.com>

On Mon, 1 Aug 2022 16:23:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
> 
> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
> 
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> --------------------------------------------------

Ok. So this is now pending removing those test parameters

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

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


From prr at openjdk.org  Thu Aug  4 20:38:34 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Aug 2022 20:38:34 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v7]
In-Reply-To: <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>
Message-ID: <6f2EK5LOI2kXLAHC_3VpQQcKmrhDdvgWq8xe7N5Gd8s=.bc71c272-98fd-483c-a8a2-107c6a83f3df@github.com>

On Tue, 2 Aug 2022 06:51:36 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 79:

> 77:      * <p>
> 78:      * NOTE: This constructor should not be called by
> 79:      * application, it is for Internal use only. When called directly

"application" -> "applications"
"Internal" -> "internal"

test/jdk/javax/swing/DebugGraphics/DebugGraphicsNPETest.java line 30:

> 28: /* @test
> 29:  * @bug 6521141
> 30:  * @key headful

Why does this test need to be headful ?

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

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


From prr at openjdk.org  Thu Aug  4 20:40:17 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Aug 2022 20:40:17 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS [v2]
In-Reply-To: <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
Message-ID: <mCX1cd7uKpCT1UZ6YTUUalru3s1RQw8qhXzNsb7uw5g=.7c49af43-9fdd-49e3-b1ed-a43e1f50ef49@github.com>

On Mon, 1 Aug 2022 14:30:54 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
>> 
>> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
>> 
>> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made DrawRotatedStringUsingRotatedFont.java headful and dropped extra test

You really should wait for the 2nd review before integrating

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

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


From achung at openjdk.org  Thu Aug  4 20:40:24 2022
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 4 Aug 2022 20:40:24 GMT
Subject: Integrated: 8169187: [macosx] Aqua:
 java/awt/image/multiresolution/MultiresolutionIconTest.java
In-Reply-To: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
References: <Akqt7GJ8mYNbqN6JVJ-0gni3qFxiXpVJOolda69UHTU=.224219d5-aac0-4a52-86ba-958844df7353@github.com>
Message-ID: <OhDqJr9D0km-SV663NYFjCT9FClSgD26I6HWExGEAZs=.3ccf77a7-40d6-4ac5-b2c8-c006a8bcf9d7@github.com>

On Fri, 8 Jul 2022 22:33:39 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removed darkening of icons on button press in Aqua to match other L&Fs. The icon darkening was causing this test to fail on MacOS.
> 
> The test is passing on all platforms after this change.

This pull request has now been integrated.

Changeset: 90257f95
Author:    Alisen Chung <achung at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90257f95058626196339c444937f037516dbd21e
Stats:     7 lines in 2 files changed: 4 ins; 1 del; 2 mod

8169187: [macosx] Aqua: java/awt/image/multiresolution/MultiresolutionIconTest.java

Reviewed-by: prr, dnguyen

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

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


From prr at openjdk.org  Thu Aug  4 20:52:57 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Aug 2022 20:52:57 GMT
Subject: RFR: 8267374: (macos) Option+Up/Down arrow dont traverse to
 beginning/end of line in textarea [v8]
In-Reply-To: <0-RBRu4rlGbERo6KF-0KdmNVX7nCGb6rkjbFDWVErcY=.6cc5faf4-9bb1-4c5d-9213-e85c3ff0f151@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
 <0-RBRu4rlGbERo6KF-0KdmNVX7nCGb6rkjbFDWVErcY=.6cc5faf4-9bb1-4c5d-9213-e85c3ff0f151@github.com>
Message-ID: <qena9xWXzcyGMCYiFfg-BgUc5EARwrQgEKj1YkEQucM=.4482a4a9-47f0-4a17-ba58-8b938b92ef17@github.com>

On Thu, 28 Jul 2022 08:39:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
>> Java does not honour these key combination in editor.
>> 
>> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Aug  4 20:54:38 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Aug 2022 20:54:38 GMT
Subject: Integrated: 8272998: ImageIO.read() throws incorrect exception type
In-Reply-To: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
References: <7P_RTUjGWttc7Wpknqa7CCPgNIssyX4xT--MjQ_R5po=.be6078e7-bb89-4b23-9b55-6d8fe93c70f6@github.com>
Message-ID: <bLkByk-qlFePtxwSpxVGkXQwZEeW4-_EufUZ3vblfy4=.32244591-b6a6-40fc-a423-af72ac061c09@github.com>

On Thu, 9 Jun 2022 19:53:22 GMT, Phil Race <prr at openjdk.org> wrote:

> ImageIO.read() only documents IOException for any kind of decoding problem and since
> it is a convenience API we don't want to start requiring applications to handle other RuntimeExceptions.
> So in the unlikely case of some problem decoding using this API, wrap any RuntimeException in
> an IIOException. This will give more stable app behaviour and still report the underlying problem.

This pull request has now been integrated.

Changeset: 6ad6b1c4
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ad6b1c454cbc41de5a401aecda910d668c71e39
Stats:     158 lines in 2 files changed: 158 ins; 0 del; 0 mod

8272998: ImageIO.read() throws incorrect exception type

Reviewed-by: aivanov, dnguyen

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

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


From prr at openjdk.org  Thu Aug  4 20:57:54 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Aug 2022 20:57:54 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in
 a button.
In-Reply-To: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
Message-ID: <5ZZiPID1A-WKy5U0TOtgXqOf-v-bXhfsH797zQ-yHcA=.b1c740bc-4a2d-48be-a7f2-9c79a1b49738@github.com>

On Tue, 2 Aug 2022 10:22:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the letter 'S' in the JButton to be underlined if JButton's text has 'S' in its string.
> This is because [**VK_F4**](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506) keycode is 0x73 (115 in decimal) which happens to be value of lowercase [**'s'** ](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(), the first index of the character (either lowecasr or uppercase) is returned as a mnemonic, which gets underlined.
> 
> Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic which corresponds to lowercase p->z

Sounds reasonable to me although I'm not an expert on mnemonic handling.

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

Marked as reviewed by prr (Reviewer).

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


From avu at openjdk.org  Thu Aug  4 21:30:41 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 4 Aug 2022 21:30:41 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives
Message-ID: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>

Do not cause redundant endEncoder calls with batch processing of drawing primitives

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

Commit messages:
 - 8291266: RenderPerfTest: missing content while rendering some primitives

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

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


From serb at openjdk.org  Thu Aug  4 21:30:41 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 4 Aug 2022 21:30:41 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives
In-Reply-To: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
Message-ID: <lvPFjvz2H1tyxuTS6c3H6hLSAgcZXaOY-5d0C3fYwaU=.32123679-d094-4807-9c19-f4913b1e9bde@github.com>

On Thu, 4 Aug 2022 21:07:02 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Do not cause redundant endEncoder calls with batch processing of drawing primitives

Is it possible to integrate DrawTest.java as a test case?

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

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


From avu at openjdk.org  Thu Aug  4 22:07:08 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Thu, 4 Aug 2022 22:07:08 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives
In-Reply-To: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
Message-ID: <xfIQP_aTUkRgYwZO_hld6bbctURk-7pBOJOIZ_9g0Tw=.38924a85-b422-43dd-b6f1-000e3aff081e@github.com>

On Thu, 4 Aug 2022 21:07:02 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Do not cause redundant endEncoder calls with batch processing of drawing primitives

Looks like the only way is to use Robot. The problem is not reproducible with VolatileImage. I'll try to come up with something reliable.

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

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


From prr at openjdk.org  Thu Aug  4 22:24:50 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Aug 2022 22:24:50 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <2bez2JZQKhsHEuZK4fLIZDOoHwFObNUsxmP4tJ5Y9H0=.acdd9bd6-dc89-4731-b082-4e2f35f3bd2e@github.com>

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

I've run all tests we have and not too surprised they pass since the affected values
probably aren't being exercised.

However I've been reading the docs about NaN and +/-0 equivalence at
https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Double.html
since if we change anything it probably ought to align with what ever says there.

Since I recalled that NaN == NaN will always return false, it seemed what you have
was not consistent with that. Whilst this is true it seems Double.equals() does the opposite .. so OK ..
although it surprised me.

But then the docs say +0 and -0 should not be equal whereas for backwards compatibility
you say you extended them being treated as equal from equals() into hashCode() ..

Not sure why only in this case was the compatibility important.

I'd like to hear what  @jddarcy (Joe Darcy) thinks about all of this.

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

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


From honkar at openjdk.org  Fri Aug  5 00:45:59 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 00:45:59 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v5]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <b9tj14p0ySfQRvXFH1qqzi14cM1bEjcAnEyZj1buf-g=.3c572326-b5e5-435d-9261-34f88e5de95b@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

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

  added Thread.sleep and changed the location of setVisible

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/994888bd..195002df

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

  Stats: 144 lines in 9 files changed: 69 ins; 46 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

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


From honkar at openjdk.org  Fri Aug  5 00:46:02 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 00:46:02 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
Message-ID: <8LPj_zkwYJMjR-tuWsCLjFteFep_Pkl_LVUGSYAIyHA=.4e52426a-7572-46fa-a67e-fead14424850@github.com>

On Thu, 21 Jul 2022 00:27:04 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added screen insets to account for taskbar position, doc changes

The recent commit has the following changes -

- Toolkit sync and Thread.sleep added to push the frame's updated location to window manager
- Position of `setVisible` for instruction frame moved from `createUI `to `positionTestWindow`. Before this change the frame was initially visible for sometime in its initial location for a few seconds before moving to its final position set in `positionTestWindow`. 
- For the same reason as above, the `setVisible` for `testWindow` is called after `positionTestWindow()` at test-level.

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

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


From serb at openjdk.org  Fri Aug  5 01:26:52 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 5 Aug 2022 01:26:52 GMT
Subject: RFR: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong
 rendering intent [v2]
In-Reply-To: <Ph_SJsWvEYetgWKE39Nvzl6d9Yc0fsZmDaZgByBk4iA=.cbb91501-6cd6-45a2-8dd7-4761c168703c@github.com>
References: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
 <DuZIpHsaFdw_cxbhiyLJ0cg4D8lNxYp2MVJ8rHB3mOI=.ce31cf20-5ca6-485b-822a-90a828dac705@github.com>
 <Ph_SJsWvEYetgWKE39Nvzl6d9Yc0fsZmDaZgByBk4iA=.cbb91501-6cd6-45a2-8dd7-4761c168703c@github.com>
Message-ID: <YMMjRS8uJwHrjF3UCvnZ0ZbTHfPCbBD9KGwrwOpKzrM=.47c5e210-0158-4322-b326-78f548b9beab@github.com>

On Sun, 17 Jul 2022 23:20:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'openjdk:master' into JDK-8288633
>>  - Update ICC_ColorSpace.java
>>  - 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong rendering intent
>
> test/jdk/java/awt/color/ICC_ColorSpace/ToFromCIEXYZRoundTrip.java line 3:
> 
>> 1: /*
>> 2:  * Copyright Amazon.com Inc. or its affiliates. All Rights Reserved.
>> 3:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 
> 2022 ?

Yes, that code seems related to the KCMS. I'll update the date.

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

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


From serb at openjdk.org  Fri Aug  5 01:35:27 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 5 Aug 2022 01:35:27 GMT
Subject: RFR: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong
 rendering intent [v3]
In-Reply-To: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
References: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
Message-ID: <RczC3O8eYXj7PPnpNefE8ffU9WD26IcaDwsxLG5ODBI=.827c202f-6abb-45fb-9464-eac5b816399d@github.com>

> The specification of the  ICC_ColorSpace.fromCIEXYZ method [says](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L428):
> 
>> * This method transforms color values using relative colorimetry, as defined by the ICC Specification.
> 
> The LCMS plugin implementation expects the rendering intent in the first part of transform:
> https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L116
> 
> But the ICC_ColorSpace.fromCIEXYZ pass "ICC_Profile.icRelativeColorimetric" to the [second ](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L534) part of transform. 
> 
> Note that ICC_ColorSpace.toCIEXYZ has a similar [specification ](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L288)is implemented [properly](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L391).

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

  Update ToFromCIEXYZRoundTrip.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9194/files
  - new: https://git.openjdk.org/jdk/pull/9194/files/045e55bf..dbe791cd

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

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

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


From aoqi at openjdk.org  Fri Aug  5 02:25:11 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Fri, 5 Aug 2022 02:25:11 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName [v2]
In-Reply-To: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
Message-ID: <71HaGffpxBkDKSvH7w9801yUv8-uEmwOPNjbD-Zij0g=.7a0fe82a-a507-4a0f-bda9-203fb075c2cc@github.com>

> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
> 
> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
> 
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> --------------------------------------------------

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

  revert test/jdk/java/beans/XMLDecoder modification by 8284161

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9704/files
  - new: https://git.openjdk.org/jdk/pull/9704/files/ef808047..f6fc43a1

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

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

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


From aoqi at openjdk.org  Fri Aug  5 02:25:11 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Fri, 5 Aug 2022 02:25:11 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
Message-ID: <38RYDqvRB9bjEQ0gPeD7g7ONm2PyoSVD50KgZwaaoao=.89701218-f6ca-431b-b56b-bcf0b5a49b35@github.com>

On Mon, 1 Aug 2022 16:23:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
> 
> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
> 
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> --------------------------------------------------

I revert the change of test/jdk/java/beans/XMLDecoder by [JDK-8284161](https://bugs.openjdk.org/browse/JDK-8284161). This also includes changing `@run main/othervm` to `@run main`. I am not sure if this is needed. All tests in test/jdk/java/beans/XMLDecoder passed with both server and zero.

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

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


From tr at openjdk.org  Fri Aug  5 05:01:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 05:01:54 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v7]
In-Reply-To: <6f2EK5LOI2kXLAHC_3VpQQcKmrhDdvgWq8xe7N5Gd8s=.bc71c272-98fd-483c-a8a2-107c6a83f3df@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>
 <6f2EK5LOI2kXLAHC_3VpQQcKmrhDdvgWq8xe7N5Gd8s=.bc71c272-98fd-483c-a8a2-107c6a83f3df@github.com>
Message-ID: <5ubvyqy3lQ3WZM-1trt-oMHow2WkMNYn00ZD3QCmz3Q=.ec59e10c-f6d9-4769-980d-733293d9525d@github.com>

On Thu, 4 Aug 2022 20:25:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> test/jdk/javax/swing/DebugGraphics/DebugGraphicsNPETest.java line 30:
> 
>> 28: /* @test
>> 29:  * @bug 6521141
>> 30:  * @key headful
> 
> Why does this test need to be headful ?

Actually not required, since no UI is used..... Will remove and test......

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

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


From tr at openjdk.org  Fri Aug  5 05:46:20 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 05:46:20 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v6]
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <vcCUXuQFJC0Txc77mJbvTOJw4MGa6jN9WhVUfJyd9cc=.37108724-ca67-46b6-9d9f-246d83190749@github.com>

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9597/files
  - new: https://git.openjdk.org/jdk/pull/9597/files/2bfb588b..53106212

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

  Stats: 8 lines in 2 files changed: 0 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9597.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9597/head:pull/9597

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


From tr at openjdk.org  Fri Aug  5 05:46:20 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 05:46:20 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v5]
In-Reply-To: <AiNiTqBW6mQ6xNdgGX4QlfAqUczpl6JVuDIHFx9lFJI=.a8d5d13c-3aae-4441-ac0a-48044c18b9d7@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <zc7his_JsVFspd0X7RYBtTTUMkbmBENPEpxAKQHbezc=.abec7553-2b60-41b8-aff9-4b7c623ba01c@github.com>
 <AiNiTqBW6mQ6xNdgGX4QlfAqUczpl6JVuDIHFx9lFJI=.a8d5d13c-3aae-4441-ac0a-48044c18b9d7@github.com>
Message-ID: <z5M3g6iSKbkoU4RjscvYnpP5TiBPsG1CaNaDBQ705gE=.0c07d566-ca52-4b87-aa76-facac3fb7ec5@github.com>

On Thu, 4 Aug 2022 18:53:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> Changes requested by aivanov (Reviewer).

@aivanov-jdk Updated your review comments. Let me know if its fine now.....?

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

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


From alanb at openjdk.org  Fri Aug  5 06:55:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Aug 2022 06:55:00 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName [v2]
In-Reply-To: <71HaGffpxBkDKSvH7w9801yUv8-uEmwOPNjbD-Zij0g=.7a0fe82a-a507-4a0f-bda9-203fb075c2cc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <71HaGffpxBkDKSvH7w9801yUv8-uEmwOPNjbD-Zij0g=.7a0fe82a-a507-4a0f-bda9-203fb075c2cc@github.com>
Message-ID: <T03e8ocoSW-lBn8UsCXCihQjP3IYqrGadbFy6YbNwMk=.91a7536d-6f4b-484c-b3db-4c7799115eb0@github.com>

On Fri, 5 Aug 2022 02:25:11 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
>> 
>> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
>> 
>> 
>> --------------------------------------------------
>> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
>> ...
>> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
>> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
>> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
>> 	... 9 more
>> ...
>> 
>> --------------------------------------------------
>> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
>> ...
>> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
>> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
>> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
>> 	... 9 more
>> ...
>> --------------------------------------------------
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert test/jdk/java/beans/XMLDecoder modification by 8284161

Marked as reviewed by alanb (Reviewer).

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

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


From aoqi at openjdk.org  Fri Aug  5 07:07:07 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Fri, 5 Aug 2022 07:07:07 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <VUAwvj9XIcUHj_6p39FQXvmebJhvAh52kbBvcmFFBio=.de2355d0-4d71-4e8e-a53c-aaee8c6865c4@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <SH61rVjJMYU3UUM1oh3xCLk0ev13zOfxr1wx97gvLqU=.fbe65bc3-adac-431c-8389-e3546bbdbc6c@github.com>
 <4_tM2zGhsWXglCYtdZqgGXMHreTRhRYnXVVgo8TvOM8=.91d4ddf2-70c7-43f5-bdc2-77a290c5d70c@github.com>
 <VUAwvj9XIcUHj_6p39FQXvmebJhvAh52kbBvcmFFBio=.de2355d0-4d71-4e8e-a53c-aaee8c6865c4@github.com>
Message-ID: <Y0arUluRXta1nSoTnfQIZxAxzriH0DbhYRk2HjFBYM4=.5b73ff40-4223-4ea8-b39a-4ee73992ebf5@github.com>

On Wed, 3 Aug 2022 05:59:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> One other comment on this is that the proposed change should mean that the tests no longer need to run with --enable-preview.
>> 
>> You've lost me all over again.
>> Why did these two tests need that in the first place and why would they no longer need it ?
>> 
>> My best guess is that it was added so that the tests deliberately provoked using continuations to verify everything worked but that with the change there's no point since it won't load any classes that use them .. ?
>
>> My best guess is that it was added so that the tests deliberately provoked using continuations to verify everything worked but that with the change there's no point since it won't load any classes that use them .. ?
> 
> That's right. These tests triggered the initialization of classes that depend on the VM being started with --enable-preview. With the proposed change here, the classes will be loaded but not initialized so it won't execute code that needs preview features to be enabled.

Thanks, @AlanBateman ! Let's wait and see if @prrace  approves the change.

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

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


From mkartashev at openjdk.org  Fri Aug  5 07:39:22 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 5 Aug 2022 07:39:22 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <jq09J-6HysZ6y3wI_-WXu-9fI42WTgFK9iN5O7IpLxI=.8e4f2e51-daa3-449a-8ec3-d010a0b5787f@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <PTnn7O1EKrKWdLcAfRe3H43Za5g8G9aTNMVbL-8KItg=.56857235-b9ad-41b5-b051-7930e8223a3e@github.com>
 <ZLjh97_0zmWK8XyJIop9R9hCIx7KkvvIrXW2iE4vn3w=.dfedff31-4d00-4565-9ebf-f5108cbd0da4@github.com>
 <jq09J-6HysZ6y3wI_-WXu-9fI42WTgFK9iN5O7IpLxI=.8e4f2e51-daa3-449a-8ec3-d010a0b5787f@github.com>
Message-ID: <91Z2aTdMF9LkLENxTOCiIS2xzs6bqhMxvUimquMhBNQ=.d776e356-be6f-4e8e-b2f3-e03bcb6c72da@github.com>

On Wed, 13 Jul 2022 08:58:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>> The code that disposes on the rendering thread is invoked from a dispose() method
>> that was on the Disposer thread. It then waits for that to finish.
>> At that time the Disposer thread is blocked so not doing anything and the render
>> thread is free to add elements to deferredRecords.
>> 
>> Correct. Now let's suppose that the rendering thread - unblocked at the time - is adding more records such that `ArrayList` needs to grow. Now `ArrayList` starts relocating its underlying storage array at the time as `dispose()` returns and we're ready for the next iteration of 
>> 
>> for (int i=0;i<deferredRecords.size(); i++) {
>> ``` 
>> loop. The next call to `ArrayList.get()` here
>> 
>> DisposerRecord rec = deferredRecords.get(i);
>> 
>> will be executed on the disposer thread simultaneously with the array relocation of `deferredRecords`. So some of the `get()` calls will return `null` as they read from initialized, but yet-to-be-relocated chunks, and some will read what essentially is garbage.
>> 
>>> Second if it is just about MT access to deferredRecords and pulling elements off
>> that queue then why aren't we getting a Java exception about concurrent modification
>> instead of a crash.
>> 
>> The race was between `ArrayList.get()` called from `clearDeferredRecords()` on a dedicated disposer thread and `ArrayList.add()` called from `pollRemove()` on a _different_ thread. AFAIK there are no safeguards against concurrent modification between those two methods (I check the implementation).
>> 
>>> And if we do somehow have two threads that end up trying to free the same data ie both executing the dispose() method of an instance
>> 
>> I didn't imply that `dispose()` was called twice on the same instance. I said "probably due to double-free" (or "bad" free in the bug description) simply because these are the checks that are usually implemented in the heap alloc/dealloc routines, so "double-free" is likely with the second free called from one of the `dispose()` methods; I have no idea who called the first `free()` and when.
>> 
>>> BTW when we run this test since it is a headless test we would never have accelerated
>> glyphs .. and the same is true of your new tests .. so I imagine in our test harness
>> and that of others too they'll all always pass.
>> 
>> Are you implying that `test/jdk/java/awt/Graphics2D/DrawString/DisposerTest.java` is useless in the headless mode? Then I can mark it as `headful`. I can also simply drop it.
>> 
>> Be that as it may, `test/jdk/sun/java2d/Disposer/TestDisposerRace.java` doesn't depend on any acceleration and is as removed from any 2D code as it can be. And it also shows the problem on Linux, making the one mentioned above somewhat superfluous.
>
>> will be executed on the disposer thread simultaneously with the array relocation of `deferredRecords`. So some of the `get()` calls will return `null` as they read from initialized, but yet-to-be-relocated chunks, and some will read what essentially is garbage.
> 
> Don't we have a similar issue in the usage of `records `and `queue`? Is it possible that the `target` object in the `add `method will be deallocated before `ref `will be added to the `records`? In that case, the next code in `run` method will fail:
> 
>     Reference<?> obj = queue.remove();
>     obj.clear();
>     DisposerRecord rec = records.remove(obj);
>     rec.dispose();
> 
> Do we need Reference.reachabilityFence at the end of the `add` or some kind of synchronization?
> 
> Note that pollRemove tries to solve that:
> 
>     DisposerRecord rec = records.remove(obj);
>     if (rec == null) { // shouldn't happen, but just in case.
>          continue;
>     }
> 
> But for sure synchronization should solve that in some better way.

@mrserb Are you OK with the current state of the PR?

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

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


From duke at openjdk.org  Fri Aug  5 08:35:46 2022
From: duke at openjdk.org (Martin Desruisseaux)
Date: Fri, 5 Aug 2022 08:35:46 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <oKGl7IGxE02L4FNArYaunkO-RSJyigo79p8Xv1njMDc=.ce92a4ef-f7fa-481d-9b30-cb21ffe7ee73@github.com>

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

Indeed, in this proposed patch +0 is considered equal to -0 mainly for preserving current behaviour. The proposed new `AffineTransform.equals(Object)` has a behaviour different than the old one only regarding NaN, which should be rare in `AffineTransform`. So for practical purposes; the `equals` method would be basically unchanged in this patch proposal.

But there is also an additional reason. It is because two `AffineTransform` instances with the same coefficients except for the sign of zero will compute the same points when a `transform(?)` method is invoked (except when a result is zero, in which case the sign of that 0 may be different in some cases). So those two transforms can be considered as equal for the purpose of transforming points. There is a possibility that some existing codes rely on this equality (which is not mathematically wrong I think), especially since negative zeros appear easily in `AffineTransform`. Consider for example a translation on only one axis (line break added for clarity):


AffineTransform[[1.0, 0.0, 2.0],
                [0.0, 1.0, 0.0]]


A call to `AffineTransform.createInverse()` gives:


AffineTransform[[1.0, 0.0, -2.0],
                [0.0, 1.0, -0.0]]


Both translation terms become negative (as expected), including zero. But transforming points with that `AffineTransform` will give results strictly identical (except for the sign of some 0 coordinate values) to an `AffineTransform` created by `getTranslateInstance(-2, 0)`, so the current behaviour of considering them as equal may not be wrong.

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

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


From psadhukhan at openjdk.org  Fri Aug  5 09:13:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 5 Aug 2022 09:13:38 GMT
Subject: RFR: 7189422: [macosx] Submenu's arrow have a wrong position
Message-ID: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>

Issue is Arrow in submenu with empty title have a wrong position in Aqua L&F as can be seen

<img width="94" alt="image" src="https://user-images.githubusercontent.com/43534309/183023538-de8e51b4-31e6-45d7-b2bd-35da5e29c1e8.png">


which is because the text being null/empty, `labelR` rectangle width/height is 0 so arrowIcon y coordinate becomes -ve as per the calculation in layoutMenuItem(). Although it seems logical to me to not show the arrow if submenu text is null, but
whereas for other L&F, it is shown as this 
for Metal
<img width="83" alt="image" src="https://user-images.githubusercontent.com/43534309/183022436-d9e8ebf1-98de-4cf6-bf43-3713357846e5.png">

for Nimbus
<img width="77" alt="image" src="https://user-images.githubusercontent.com/43534309/183022730-35d170b2-71c6-4231-9a03-880107dc49c6.png">

so the fix is made in Aqua L&F to show as other L&F as
<img width="92" alt="image" src="https://user-images.githubusercontent.com/43534309/183023030-7356086d-957c-4e0d-bd52-bdf3493a96b0.png">

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

Commit messages:
 - Fix
 - 7189422: [macosx] Submenu's arrow have a wrong position

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

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


From tr at openjdk.org  Fri Aug  5 09:32:05 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 09:32:05 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v8]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <MkJf9GHS6xwK8k5GOZNwWFR0a0RudXPjye2X996_EpI=.e6f46aab-1b4f-43a5-8504-d85ca3e5fd32@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

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

 - Updated based on review comments
 - Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/8f5cfb50..063248ab

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

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

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


From tr at openjdk.org  Fri Aug  5 09:32:06 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 09:32:06 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v4]
In-Reply-To: <7jFj84z3Ga9TmOmjrONunWq8FvrSqzkepEpy-8p61lk=.c6e379a6-d411-4ff6-8e8d-b2e6c132a5d2@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <zKth_i2qEYmE3F0eb1AXP33SFkOUGjx6HeizRFi4Ef0=.105f1318-4248-46e5-9155-12610fbed0b2@github.com>
 <7jFj84z3Ga9TmOmjrONunWq8FvrSqzkepEpy-8p61lk=.c6e379a6-d411-4ff6-8e8d-b2e6c132a5d2@github.com>
Message-ID: <Vj1UDY9EDaog7onGX226b2Wj2AEVVPcv2vwyXBXmd3s=.916de39a-ce0b-4dd0-81c8-ef53b8281881@github.com>

On Thu, 28 Jul 2022 18:11:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed whitespace error
>
> You wrote " The graphics object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. "
> 
> which reads a bit like if the user does
> DebugGraphics dg = new DebugGraphics();
> they must then follow it up with
> dg.setGraphics(g);
> however there's no such method.
> 
> So any DebugGraphics created this way is useless.
> You can't use it for debugging 
> Making it protected won't prevent mis-use.
> Someone could subclass and provide a public no-args constructor and the problem will recur.
> 
> The javadoc for the class says :
> DebugGraphics objects are rarely created by hand
> 
> So likely no one should be doing this.
> 
> I'd just add javadoc saying "This constructor should not be called by applications, it
> is for internal use only. When called directly it will create an un-usable instance".
> 
> The only other thing I can think of is to try to figure out by using
> https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/StackWalker.html#getCallerClass())
> 
> if it was called from outside DebugGraphics, and if so install some other graphics instead.
> 
> something like .. 
> if (graphics == null && stackWalker.getCallerClass() != this.class ) {
>    BufferedImage bi = new BufferedImage(1,1,BufferedImage.TYPE_INT_RGB);
>    graphics = bi.createGraphics();
> }

@prrace, I have updated the PR, let me know if its ok now......

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

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


From tr at openjdk.org  Fri Aug  5 09:32:08 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 09:32:08 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v7]
In-Reply-To: <6f2EK5LOI2kXLAHC_3VpQQcKmrhDdvgWq8xe7N5Gd8s=.bc71c272-98fd-483c-a8a2-107c6a83f3df@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <ta9PgDMudNECYqjzr1PEcJzsJ3SCtYYNgc3UQWJt1I0=.daa55722-b575-4124-840b-766eb2dcc093@github.com>
 <6f2EK5LOI2kXLAHC_3VpQQcKmrhDdvgWq8xe7N5Gd8s=.bc71c272-98fd-483c-a8a2-107c6a83f3df@github.com>
Message-ID: <Pp7S7_mfQtdpz44h9IIpbdaIRoj1FekIsgjEPoQEBkg=.aa8bd7cc-2180-4b23-a8b1-42b8091fd6e4@github.com>

On Thu, 4 Aug 2022 20:24:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 79:
> 
>> 77:      * <p>
>> 78:      * NOTE: This constructor should not be called by
>> 79:      * application, it is for Internal use only. When called directly
> 
> "application" -> "applications"
> "Internal" -> "internal"

Updated.

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

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


From jwaters at openjdk.org  Fri Aug  5 09:58:05 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 5 Aug 2022 09:58:05 GMT
Subject: RFR: 8291959: FileFontStrike#initNative does not properly initialize
 IG Table on Windows
Message-ID: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>

FileFontStrike#initNative calls memset with LCDLUTCOUNT (the maximum length) as the number of bytes to zero out, which is incorrect as the elements are not 1 byte in size (unsigned char*), and will result in only part of the IG Table being correctly zeroed. This is more correctly resolved by passing sizeof igLUTable to memset instead.

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

Commit messages:
 - Pass proper byte size to memset

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

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


From psadhukhan at openjdk.org  Fri Aug  5 10:54:50 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 5 Aug 2022 10:54:50 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v8]
In-Reply-To: <MkJf9GHS6xwK8k5GOZNwWFR0a0RudXPjye2X996_EpI=.e6f46aab-1b4f-43a5-8504-d85ca3e5fd32@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <MkJf9GHS6xwK8k5GOZNwWFR0a0RudXPjye2X996_EpI=.e6f46aab-1b4f-43a5-8504-d85ca3e5fd32@github.com>
Message-ID: <Kqv58GXv2jWt48Cktoek5rJre6Uc0CoT8B1hgf4HCg8=.babd51cb-33c2-41ef-8eef-a655a097f37f@github.com>

On Fri, 5 Aug 2022 09:32:05 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated based on review comments
>  - Updated based on review comments

test/jdk/javax/swing/DebugGraphics/DebugGraphicsNPETest.java line 37:

> 35: public class DebugGraphicsNPETest {
> 36:     public static void main(String[] args) throws Exception {
> 37:         SwingUtilities.invokeAndWait(new Runnable() {

No need of using EDT here as no Swing components in used. You can just move runTest() lines in main..

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

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


From tr at openjdk.org  Fri Aug  5 11:35:54 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 11:35:54 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v9]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/063248ab..e9b164d1

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

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

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


From tr at openjdk.org  Fri Aug  5 11:35:56 2022
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Aug 2022 11:35:56 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v8]
In-Reply-To: <Kqv58GXv2jWt48Cktoek5rJre6Uc0CoT8B1hgf4HCg8=.babd51cb-33c2-41ef-8eef-a655a097f37f@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <MkJf9GHS6xwK8k5GOZNwWFR0a0RudXPjye2X996_EpI=.e6f46aab-1b4f-43a5-8504-d85ca3e5fd32@github.com>
 <Kqv58GXv2jWt48Cktoek5rJre6Uc0CoT8B1hgf4HCg8=.babd51cb-33c2-41ef-8eef-a655a097f37f@github.com>
Message-ID: <NpjVqSXwLLpHYVszetWGwE8Hhj3zg-kQdCDTfXr2Joc=.298fce7d-e751-4e73-8735-88a7e39d2064@github.com>

On Fri, 5 Aug 2022 10:52:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Updated based on review comments
>>  - Updated based on review comments
>
> test/jdk/javax/swing/DebugGraphics/DebugGraphicsNPETest.java line 37:
> 
>> 35: public class DebugGraphicsNPETest {
>> 36:     public static void main(String[] args) throws Exception {
>> 37:         SwingUtilities.invokeAndWait(new Runnable() {
> 
> No need of using EDT here as no Swing components in used. You can just move runTest() lines in main..

Yeah right. I have updated the test @prsadhuk

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

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


From aivanov at openjdk.org  Fri Aug  5 12:56:02 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 5 Aug 2022 12:56:02 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v6]
In-Reply-To: <vcCUXuQFJC0Txc77mJbvTOJw4MGa6jN9WhVUfJyd9cc=.37108724-ca67-46b6-9d9f-246d83190749@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <vcCUXuQFJC0Txc77mJbvTOJw4MGa6jN9WhVUfJyd9cc=.37108724-ca67-46b6-9d9f-246d83190749@github.com>
Message-ID: <ha8qAmnWDU22uxTQgl9ff28K8sX1SFr_oPZXBexTxBM=.d23f14f5-4bcf-4d86-afdb-9b389098b34a@github.com>

On Fri, 5 Aug 2022 05:46:20 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 42:

> 40: import java.nio.file.Files;
> 41: import java.nio.file.Path;
> 42: import java.nio.file.Paths;

`Paths` is unused now.
`Path` could be removed too: see below.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicFileChooserUI.java line 725:

> 723:                                 if ((chooser.isFileSelectionEnabled() && !isDir)
> 724:                                     || (chooser.isDirectorySelectionEnabled()
> 725:                                         && (fsv.isFileSystem(f) || Files.isSymbolicLink(path))

You can inline `f.toPath()` in line 725 and remove the local variable `path` like this:


                                        && (fsv.isFileSystem(f) || Files.isSymbolicLink(f.toPath()))

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

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


From duke at openjdk.org  Fri Aug  5 12:59:48 2022
From: duke at openjdk.org (Nikita Gubarkov)
Date: Fri, 5 Aug 2022 12:59:48 GMT
Subject: RFR: 8269806: Emoji rendering on Linux [v13]
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <Drs_ayWoNKbaYD_kD18P3QgZd0cqNLnLIixjulgJc0g=.aa1aa625-62a4-4c27-ab68-22deca82650b@github.com>

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

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

  Fix italic and bold styles for colored outline glyphs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/4798/files
  - new: https://git.openjdk.org/jdk/pull/4798/files/83d5da54..c2506a37

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

  Stats: 17 lines in 2 files changed: 6 ins; 3 del; 8 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  Fri Aug  5 13:27:54 2022
From: duke at openjdk.org (Dio Brando)
Date: Fri, 5 Aug 2022 13:27:54 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v6]
In-Reply-To: <vcCUXuQFJC0Txc77mJbvTOJw4MGa6jN9WhVUfJyd9cc=.37108724-ca67-46b6-9d9f-246d83190749@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <vcCUXuQFJC0Txc77mJbvTOJw4MGa6jN9WhVUfJyd9cc=.37108724-ca67-46b6-9d9f-246d83190749@github.com>
Message-ID: <4f5dQLQdHnebMBJkZ42Hr1yo2PqM4VL_K4aUMcP1vEw=.36989c7c-e9e5-43e0-a8b6-3354d66d459b@github.com>

On Fri, 5 Aug 2022 05:46:20 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by AJ1032480 at github.com (no known OpenJDK username).

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

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


From duke at openjdk.org  Fri Aug  5 14:49:52 2022
From: duke at openjdk.org (Dio Brando)
Date: Fri, 5 Aug 2022 14:49:52 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <HMylfFqWI4MYphhCq76haE8jRT9jbp9g4p4Erpmc19s=.2b8296f3-0cdb-4cb5-bb47-5134e32d0a12@github.com>

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

Have you checked all tests ? I did not see it

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

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


From duke at openjdk.org  Fri Aug  5 14:54:54 2022
From: duke at openjdk.org (Dio Brando)
Date: Fri, 5 Aug 2022 14:54:54 GMT
Subject: RFR: 7189422: [macosx] Submenu's arrow have a wrong position
In-Reply-To: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
References: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
Message-ID: <lSqfcEaM0WwvAQi6r_giM6lYlH6Oo1EMkzcyELI9trw=.397e9ccf-304f-4902-bd39-0b58975bf6d5@github.com>

On Fri, 5 Aug 2022 08:58:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is Arrow in submenu with empty title have a wrong position in Aqua L&F as can be seen
> 
> <img width="94" alt="image" src="https://user-images.githubusercontent.com/43534309/183023538-de8e51b4-31e6-45d7-b2bd-35da5e29c1e8.png">
> 
> 
> which is because the text being null/empty, `labelR` rectangle width/height is 0 so arrowIcon y coordinate becomes -ve as per the calculation in layoutMenuItem(). Although it seems logical to me to not show the arrow if submenu text is null, but
> whereas for other L&F, it is shown as this 
> for Metal
> <img width="83" alt="image" src="https://user-images.githubusercontent.com/43534309/183022436-d9e8ebf1-98de-4cf6-bf43-3713357846e5.png">
> 
> for Nimbus
> <img width="77" alt="image" src="https://user-images.githubusercontent.com/43534309/183022730-35d170b2-71c6-4231-9a03-880107dc49c6.png">
> 
> so the fix is made in Aqua L&F to show as other L&F as
> <img width="92" alt="image" src="https://user-images.githubusercontent.com/43534309/183023030-7356086d-957c-4e0d-bd52-bdf3493a96b0.png">

Changes requested by AJ1032480 at github.com (no known OpenJDK username).

src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 496:

> 494:         if (!isTopLevelMenu) {
> 495:             //    if ( GetSysDirection() < 0 ) hierRect.right = hierRect.left + w + 4;
> 496:             //    else hierRect.left = hierRect.right - w - 4;

delete unused code

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

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


From duke at openjdk.org  Fri Aug  5 14:56:04 2022
From: duke at openjdk.org (Dio Brando)
Date: Fri, 5 Aug 2022 14:56:04 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v9]
In-Reply-To: <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>
Message-ID: <JDa5ctOl24gM9DBvpwOI2qrMUblSlZG4a6SBJrWwugA=.73d16a18-844e-4325-8651-c9aac27ff78a@github.com>

On Fri, 5 Aug 2022 11:35:54 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by AJ1032480 at github.com (no known OpenJDK username).

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

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


From duke at openjdk.org  Fri Aug  5 15:00:54 2022
From: duke at openjdk.org (Dio Brando)
Date: Fri, 5 Aug 2022 15:00:54 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName [v2]
In-Reply-To: <71HaGffpxBkDKSvH7w9801yUv8-uEmwOPNjbD-Zij0g=.7a0fe82a-a507-4a0f-bda9-203fb075c2cc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <71HaGffpxBkDKSvH7w9801yUv8-uEmwOPNjbD-Zij0g=.7a0fe82a-a507-4a0f-bda9-203fb075c2cc@github.com>
Message-ID: <MWrzOa9QJnztXP5_fjFvuTcCTSwzERGl92PuqczKm9g=.38c1c4ef-89c6-4aee-892f-52806d293e2c@github.com>

On Fri, 5 Aug 2022 02:25:11 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
>> 
>> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
>> 
>> 
>> --------------------------------------------------
>> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
>> ...
>> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
>> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
>> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
>> 	... 9 more
>> ...
>> 
>> --------------------------------------------------
>> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
>> ...
>> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
>> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
>> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
>> 	... 9 more
>> ...
>> --------------------------------------------------
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert test/jdk/java/beans/XMLDecoder modification by 8284161

Marked as reviewed by AJ1032480 at github.com (no known OpenJDK username).

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

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


From prr at openjdk.org  Fri Aug  5 16:40:13 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 5 Aug 2022 16:40:13 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v9]
In-Reply-To: <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>
Message-ID: <cQzs-ZKVqbLMJfVMOQdAYne3Oas1vlJVV3u5QXstxA0=.8179b5bd-69b8-4a46-a2c2-85712822caab@github.com>

On Fri, 5 Aug 2022 11:35:54 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Fri Aug  5 17:36:03 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 5 Aug 2022 17:36:03 GMT
Subject: RFR: 7189422: [macosx] Submenu's arrow have a wrong position
In-Reply-To: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
References: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
Message-ID: <GifucPQelmYdGJCQToQHMSAM1qDGn8H24eCaDTxwZKA=.21cd6c4b-f919-4b3b-8b4e-098ddb473114@github.com>

On Fri, 5 Aug 2022 08:58:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is Arrow in submenu with empty title have a wrong position in Aqua L&F as can be seen
> 
> <img width="94" alt="image" src="https://user-images.githubusercontent.com/43534309/183023538-de8e51b4-31e6-45d7-b2bd-35da5e29c1e8.png">
> 
> 
> which is because the text being null/empty, `labelR` rectangle width/height is 0 so arrowIcon y coordinate becomes -ve as per the calculation in layoutMenuItem(). Although it seems logical to me to not show the arrow if submenu text is null, but
> whereas for other L&F, it is shown as this 
> for Metal
> <img width="83" alt="image" src="https://user-images.githubusercontent.com/43534309/183022436-d9e8ebf1-98de-4cf6-bf43-3713357846e5.png">
> 
> for Nimbus
> <img width="77" alt="image" src="https://user-images.githubusercontent.com/43534309/183022730-35d170b2-71c6-4231-9a03-880107dc49c6.png">
> 
> so the fix is made in Aqua L&F to show as other L&F as
> <img width="92" alt="image" src="https://user-images.githubusercontent.com/43534309/183023030-7356086d-957c-4e0d-bd52-bdf3493a96b0.png">

src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 498:

> 496:             //    else hierRect.left = hierRect.right - w - 4;
> 497: 
> 498:             arrowIconR.x = Math.abs((viewR.width - arrowIconR.width) + 1);

May I take it that you verified this doesn't have any adverse effects on submenus with text :?

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

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


From honkar at openjdk.org  Fri Aug  5 17:42:03 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 17:42:03 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

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

  added null check in positionWindow

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/195002df..96629ad3

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

  Stats: 26 lines in 2 files changed: 12 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

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


From honkar at openjdk.org  Fri Aug  5 17:42:05 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 17:42:05 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v5]
In-Reply-To: <b9tj14p0ySfQRvXFH1qqzi14cM1bEjcAnEyZj1buf-g=.3c572326-b5e5-435d-9261-34f88e5de95b@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <b9tj14p0ySfQRvXFH1qqzi14cM1bEjcAnEyZj1buf-g=.3c572326-b5e5-435d-9261-34f88e5de95b@github.com>
Message-ID: <ERc9LMwhHiZm1gRj_MD4MOXrwORgHhcWQwrBGXfdKds=.cebebac8-939c-42c0-90fd-6df6655c412f@github.com>

On Fri, 5 Aug 2022 00:45:59 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added Thread.sleep and changed the location of setVisible

Added null check for `testWindow` in `positionWindow` as the following line             `testWindow.setLocation(.....);` will produce NPE if `positionWindow` is called with `testWindow = null`. 

Additionally, some tests do not require a testWindow, for example [TrayIconScalingTest.java](https://github.com/openjdk/jdk/blob/f9bb3676e3d2c5fe0ae505d3bcbf434f7acb524f/test/jdk/java/awt/TrayIcon/TrayIconScalingTest.java#L81) in which case we can call `PassFailJFrame.positionTestWindow(null,PassFailJFrame.Position.HORIZONTAL);`

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

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


From honkar at openjdk.org  Fri Aug  5 17:44:05 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 17:44:05 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v3]
In-Reply-To: <D7CXLkmYxl9GC4AoLqbovxPebCPHiOvvvIMpZZ59SiI=.96c517ae-224e-48e2-bc6a-c191b60acda7@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <sSB3ekjiQkvFdfn9P-augke8mRW6EUMMMkkaa2nWmZQ=.abc7a8ae-fc04-44d3-a9f5-0a0ad3b1e79a@github.com>
 <7u9z5a1SZWJXw3F8L8gfskhW_QQSMMDHlCe-C54egSo=.61e18616-a7a8-4ff9-afb7-3e4fd63a00ba@github.com>
 <t8xPkoSdyZSv12DU8L94WprPa8dLKoHxWJtp6SjLviY=.ec35cfd7-c57d-4aa8-b7e8-5cd2dbf12951@github.com>
 <m7qH0jhD85QVNoeNz4MmX6S9jzmxr_gCZ6m35SRrKQM=.c413bfd2-de5a-4c39-9f72-c420feaf7465@github.com>
 <R2-GUx4MtWf2h38flK2aX4grD5hQEmRyfNt-4vEc06U=.611b791c-9217-440d-b0d3-99b8d6cbc104@github.com>
 <Oio8L0XvJUNU9WJkKJRsFli6EUkVDe8hUgCy4vOFh3g=.ac2c19a6-d11a-45ff-9cf6-7c34e87cc526@github.com>
 <D7CXLkmYxl9GC4AoLqbovxPebCPHiOvvvIMpZZ59SiI=.96c517ae-224e-48e2-bc6a-c191b60acda7@github.com>
Message-ID: <YgfOkup16rug39ReXiBJAypffHdAnh5QXroiUN_LGOo=.e63b11dc-7e95-408c-87e1-b73547c416d0@github.com>

On Fri, 22 Jul 2022 20:31:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Following is a proposed solution to push the latest position changes to the window manager.
>> 
>> The get and setLocation calls are wrapped in invokeLater(). Robot.waitForIdle() are added between setLocation() and the subsequent getLocation() calls. The waitForIdle() calls ensures that any pending location updates are pushed to the window manager before the new location of the frame is in turn used to position the testWindow.
>> 
>> In multiple test window cases ONLY the test instruction frame and the main/root test window are positioned using `positionTestWindow()`, the rest of the windows are positioned within EDT at test-level.
>> 
>> **Impact of the proposed fix:** 
>> With this change `positionTestWindow()` can no longer be called on EDT at test-level, hence any existing manual tests calling this method on EDT requires changes.
>> 
>> For example: In this particular test, the following line `PassFailJFrame.positionTestWindow(frame,PassFailJFrame.Position.HORIZONTAL)` should be called after `createAndShowGUI()`
>> 
>> https://github.com/openjdk/jdk/blob/d333df8ff59c6242171da1a6d02d05e6a8e65c9d/test/jdk/javax/swing/JComboBox/JComboBoxActionEvent.java#L75
>>  
>> 
>> public static void positionTestWindow(Window testWindow, Position position) throws AWTException {
>> 
>>         if (isEventDispatchThread()) {
>>             throw new Exception("positionTestWindow() should not be called on EDT");
>>         }
>> 
>>         robot = new Robot();
>>         Dimension screenSize = Toolkit.getDefaultToolkit().getScreenSize();
>> 
>>         if (position.equals(Position.HORIZONTAL)) {
>>             SwingUtilities.invokeAndWait(() -> {
>>                 int newX = ((screenSize.width / 2) - frame.getWidth());
>>                 frame.setLocation(newX, frame.getY());
>>            });
>>             // waits until the queue is flushed
>>             robot.waitForIdle();
>>             robot.delay(300);
>> 
>>              SwingUtilities.invokeAndWait(() -> testWindow.setLocation((frame.getX() +
>>                                              frame.getWidth() + 5), frame.getY()));
>> 
>>         } else if (position.equals(Position.VERTICAL)) {
>>              SwingUtilities.invokeAndWait(() -> {
>>                 int newY = ((screenSize.height / 2) - frame.getHeight());
>>                 frame.setLocation(frame.getX(), newY);
>>             });
>> 
>>             robot.waitForIdle();
>>             robot.delay(300);
>> 
>>             SwingUtilities.invokeAndWait(() -> testWindow.setLocation(frame.getX(),
>>                                             (frame.getY() + frame.getHeight() + 5)));
>> 
>>         } else if (position.equals(Position.TOP_LEFT_CORNER)) {
>>              SwingUtilities.invokeAndWait(() -> {
>>                 GraphicsConfiguration gc = GraphicsEnvironment.getLocalGraphicsEnvironment()
>>                         .getDefaultScreenDevice().getDefaultConfiguration();
>>                 Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
>>                 frame.setLocation(screenInsets.left, screenInsets.top);
>>             });
>> 
>>             robot.waitForIdle();
>>             robot.delay(300);
>> 
>>              SwingUtilities.invokeAndWait(() -> testWindow.setLocation((frame.getX() +
>>                    frame.getWidth() + 5), frame.getY()));
>>         }
>>     }
>
> We should discuss that impact. 
> This method is useful to simplify the logic of individual tests but is it now becoming awkward to use ?
> Or is it something that we should have required from the beginning  ?
> And why invokeLater and not invokeAndWait ? I'd have expected Later to not work for this case ..

@prrace Updated the PR  - added Toolkit.sync and Thread.sleep. Additionally, added few more changes as mentioned here - https://github.com/openjdk/jdk/pull/9525#issuecomment-1205915695 & https://github.com/openjdk/jdk/pull/9525#issuecomment-1206690566

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

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


From prr at openjdk.org  Fri Aug  5 17:49:04 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 5 Aug 2022 17:49:04 GMT
Subject: RFR: 8291959: FileFontStrike#initNative does not properly
 initialize IG Table on Windows
In-Reply-To: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
References: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
Message-ID: <mUazLHaKq50lseotRQkJY_Y9dR6-j_S0cKFJPu6o4xo=.f3f18c44-2879-4be9-a8cd-594bf58118ed@github.com>

On Fri, 5 Aug 2022 09:46:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> FileFontStrike#initNative calls memset with LCDLUTCOUNT (the maximum length) as the number of bytes to zero out, which is incorrect as the elements are not 1 byte in size (unsigned char*), and will result in only part of the IG Table being correctly zeroed. This is more correctly resolved by passing sizeof igLUTable to memset instead.

Marked as reviewed by prr (Reviewer).

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

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


From avu at openjdk.org  Fri Aug  5 18:01:26 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 5 Aug 2022 18:01:26 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives [v2]
In-Reply-To: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
Message-ID: <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>

> Do not cause redundant endEncoder calls with batch processing of drawing primitives

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

  8291266: RenderPerfTest: missing content while rendering some primitives
  
  Added regression test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9756/files
  - new: https://git.openjdk.org/jdk/pull/9756/files/a55f8f17..26a9e3f0

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

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

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


From prr at openjdk.org  Fri Aug  5 18:14:02 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 5 Aug 2022 18:14:02 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives [v2]
In-Reply-To: <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
 <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
Message-ID: <YdITOLlNGgLG4pk_sWwxfVO5DYEmUUGSovJ_hUXWxVk=.e1c93269-93ae-42e2-8560-9d2da987d971@github.com>

On Fri, 5 Aug 2022 18:01:26 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Do not cause redundant endEncoder calls with batch processing of drawing primitives
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291266: RenderPerfTest: missing content while rendering some primitives
>   
>   Added regression test

Does this only show up as a problem on certain configurations ?
I ran your original test on my 16" x64 macbook pro and I wasn't sure what it was trying to show ...

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

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


From aivanov at openjdk.org  Fri Aug  5 19:03:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 5 Aug 2022 19:03:23 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
Message-ID: <elkPAk4B6beav-tlm8_RPMUCNxGVwBF9yWp9Cy4u0nU=.8b867f0d-d5ef-45dc-bdf8-643a4409e916@github.com>

On Thu, 28 Jul 2022 10:08:24 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   creating and deleting test files dynamically

There are many comments. Could you, @kumarabhi006, summarise the approach taken, please?

src/java.desktop/share/classes/sun/swing/FilePane.java line 1235:

> 1233:             DecimalFormat df = new DecimalFormat("0.0");
> 1234:             double val = len/baseFileSize;
> 1235:             return  Double.valueOf(df.format(val));

Can we achieve the same effect without converting the value from double to string and back to double?

The returned value is `(len / 100L) / 10.0d`.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 62:

> 60:         Path dir = Paths.get(System.getProperty("test.src"));
> 61:         String [] tempFilesName = {"2.5-KB-File","2.8-MB-File","999-KB-File","1000-KB-File","2047-Byte-File","Empty-File"};
> 62:         int [] tempFilesSize = {2500, 2800000,999000,1000000,2047,0};

Does it make sense to sort the files by size by prefixing them? "1-Empty-File", "2-File-2047-Byte"?

Add a space after the commas.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 66:

> 64:         for (int i = 0 ; i < tempFilesName.length ; i++) {
> 65:             tempFilePaths[i] = dir.resolve(tempFilesName[i]);
> 66:         }

Can't the body of this for-loop be part of the next one?

There should be no space before the semi-colon.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 72:

> 70:             for (int i = 0 ; i < tempFilePaths.length ; i++) {
> 71:                 if (!Files.exists(tempFilePaths[i])){
> 72:                     RandomAccessFile f = new RandomAccessFile(tempFilePaths[i].toString(), "rw");

Suggestion:

                    RandomAccessFile f = new RandomAccessFile(tempFilePaths[i].toFile(), "rw");

would be more effective. The string version will create a `File` object internally.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 84:

> 82:         fc.showOpenDialog(null);
> 83: 
> 84:         // delete temp files

For delete to be run, the JFileChooser should be dismissed before the tester presses Pass or Fail.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 87:

> 85:         try {
> 86:             for (int i = 0 ; i < tempFilePaths.length ; ++i) {
> 87:                 Files.deleteIfExists(Paths.get(tempFilePaths[i].toString()));

Suggestion:

                Files.deleteIfExists(tempFilePaths[i]);


You already have `Path` objects, there's no need to convert them to a `String` and then back to `Path`.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 91:

> 89:         } catch (IOException ex) {
> 90:             throw new RuntimeException(ex);
> 91:         }

Probably, errors during test clean-up are not as important to fail the test?

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 99:

> 97:         SwingUtilities.invokeAndWait(() -> {
> 98:             frame = new JFrame();
> 99:             PassFailJFrame.addTestWindow(frame);

You don't use a secondary frame. Maybe skip creating it?

Alternatively, you can add the `JFileChooser` as the content of the frame as it's done in #9597.

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

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


From aivanov at openjdk.org  Fri Aug  5 19:08:14 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 5 Aug 2022 19:08:14 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
Message-ID: <uMedHsG6u8DhfYpNS6Dsf7ZIJ8orstwrtnIBe2PPl5A=.b8802967-853f-4424-994f-338967f66151@github.com>

On Thu, 28 Jul 2022 10:08:24 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 bytes.
>> Manual Test Case "ZeroFileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   creating and deleting test files dynamically

Does the size formatting respect the user's setting for the decimal symbol?

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

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


From aivanov at openjdk.org  Fri Aug  5 19:21:23 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 5 Aug 2022 19:21:23 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
Message-ID: <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>

On Fri, 5 Aug 2022 17:42:03 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added null check in positionWindow

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

> 295:                 .getDefaultScreenDevice().getDefaultConfiguration();
> 296:         Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
> 297: 

I suggest separating the logic to calculate coordinates into a separate function, or save them into a local variable.

Then call `sync` and `sleep`. Or this sequence could be extracted into its own helper method to avoid code duplication, it's repeated at least twice.

Shall this method call `window.setVisible(true)` automatically?

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

> 307:             } catch (InterruptedException e) {
> 308:                 e.printStackTrace();
> 309:             }

Is it safe to call on EDT?

If `positionTestWindow` is not to be called on EDT, should it be enforced?

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

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


From honkar at openjdk.org  Fri Aug  5 19:40:03 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 19:40:03 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
Message-ID: <Tz48QVf0QR46uw-D-Fc9LwhizwD3rsFa9taT4y8RVJU=.81a78f59-74fa-4771-9b7d-d0357f758ba0@github.com>

On Fri, 5 Aug 2022 19:13:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added null check in positionWindow
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 297:
> 
>> 295:                 .getDefaultScreenDevice().getDefaultConfiguration();
>> 296:         Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
>> 297: 
> 
> I suggest separating the logic to calculate coordinates into a separate function, or save them into a local variable.
> 
> Then call `sync` and `sleep`. Or this sequence could be extracted into its own helper method to avoid code duplication, it's repeated at least twice.
> 
> Shall this method call `window.setVisible(true)` automatically?

@aivanov-jdk As suggested, separating the common code into a helper method would make the code look cleaner. 

Earlier I did think about having the setVisible for both the testWindow and instruction frame within the positionWindow but usually at the test-level, the user would be in the habit of creating the testWindow and setting its visibility to true when creating test UI. Hence left it to be set at test-level. I can change it, if this approach is better.

Either way we need to make minor changes to existing manual tests - **remove** (in case we add testWindow.setVisible(true) to PassFailJFrame) or **reposition** (in case we retain it at test-level).

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

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


From prr at openjdk.org  Fri Aug  5 20:14:15 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 5 Aug 2022 20:14:15 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
Message-ID: <EKx_2NKE01mMHILo97CURVvun_CuWTOJH9S63DXqKCM=.8751948e-3d90-488b-9f43-ba5e8822d6a0@github.com>

On Fri, 5 Aug 2022 19:18:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added null check in positionWindow
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 309:
> 
>> 307:             } catch (InterruptedException e) {
>> 308:                 e.printStackTrace();
>> 309:             }
> 
> Is it safe to call on EDT?
> 
> If `positionTestWindow` is not to be called on EDT, should it be enforced?

The intention is that it can be called either way - on or off.

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

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


From aivanov at openjdk.org  Fri Aug  5 20:18:08 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 5 Aug 2022 20:18:08 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <EKx_2NKE01mMHILo97CURVvun_CuWTOJH9S63DXqKCM=.8751948e-3d90-488b-9f43-ba5e8822d6a0@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
 <EKx_2NKE01mMHILo97CURVvun_CuWTOJH9S63DXqKCM=.8751948e-3d90-488b-9f43-ba5e8822d6a0@github.com>
Message-ID: <ZbahauO8GYjpIGPr3_iKcZKz0fKt8ZoYcumORI543t8=.f868066f-706a-4ee0-956e-d301e4120658@github.com>

On Fri, 5 Aug 2022 20:10:48 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 309:
>> 
>>> 307:             } catch (InterruptedException e) {
>>> 308:                 e.printStackTrace();
>>> 309:             }
>> 
>> Is it safe to call on EDT?
>> 
>> If `positionTestWindow` is not to be called on EDT, should it be enforced?
>
> The intention is that it can be called either way - on or off.

Is that possible? Toolkit thread is not EDT, therefore native events are processed, it's probably enough to update the frame coordinates while EDT is blocked and doesn't handle events.

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

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


From prr at openjdk.org  Fri Aug  5 20:30:04 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 5 Aug 2022 20:30:04 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <ZbahauO8GYjpIGPr3_iKcZKz0fKt8ZoYcumORI543t8=.f868066f-706a-4ee0-956e-d301e4120658@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
 <EKx_2NKE01mMHILo97CURVvun_CuWTOJH9S63DXqKCM=.8751948e-3d90-488b-9f43-ba5e8822d6a0@github.com>
 <ZbahauO8GYjpIGPr3_iKcZKz0fKt8ZoYcumORI543t8=.f868066f-706a-4ee0-956e-d301e4120658@github.com>
Message-ID: <aZjyMdRQnQaMIEBk_7P8BHNNA7UK8hQ8Sz1IBxiPlVY=.f6dd46f7-6221-421c-ac90-09a23a2bfc39@github.com>

On Fri, 5 Aug 2022 20:14:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The intention is that it can be called either way - on or off.
>
> Is that possible? Toolkit thread is not EDT, therefore native events are processed, it's probably enough to update the frame coordinates while EDT is blocked and doesn't handle events.

Can you expand on what you mean ? 
What's the problem with native events being processed ? We want that.
And this obviously isn't being called on the toolkit thread.

This change isn't doing anything to that method that might change threading reqts or rules of use.
Any problems already existed. What is being changed (apart from adding the new API) is just to make it more robust.

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

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


From avu at openjdk.org  Fri Aug  5 21:04:08 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 5 Aug 2022 21:04:08 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives [v2]
In-Reply-To: <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
 <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
Message-ID: <vHedKIal6caaVnPqqO9kTLaEzt9erP3wqK_sgapALYU=.38fc66ef-2bb4-4a5c-9bb6-bd71f053148c@github.com>

On Fri, 5 Aug 2022 18:01:26 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Do not cause redundant endEncoder calls with batch processing of drawing primitives
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291266: RenderPerfTest: missing content while rendering some primitives
>   
>   Added regression test

The problem is only reproducible on M1 hardware (I've just double-checked that it's not reproducible on x64). The idea of the test is to trigger batch rendering introduced in [JDK-8288948](https://bugs.openjdk.org/browse/JDK-8288948)

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

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


From honkar at openjdk.org  Fri Aug  5 21:04:22 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 21:04:22 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <aZjyMdRQnQaMIEBk_7P8BHNNA7UK8hQ8Sz1IBxiPlVY=.f6dd46f7-6221-421c-ac90-09a23a2bfc39@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
 <EKx_2NKE01mMHILo97CURVvun_CuWTOJH9S63DXqKCM=.8751948e-3d90-488b-9f43-ba5e8822d6a0@github.com>
 <ZbahauO8GYjpIGPr3_iKcZKz0fKt8ZoYcumORI543t8=.f868066f-706a-4ee0-956e-d301e4120658@github.com>
 <aZjyMdRQnQaMIEBk_7P8BHNNA7UK8hQ8Sz1IBxiPlVY=.f6dd46f7-6221-421c-ac90-09a23a2bfc39@github.com>
Message-ID: <t74Ot8hsPx_cN5sZLuDm0Kj48sg-5VEiEuesQlKFIgM=.e7cd51d4-491c-4403-8940-b85bbc515c1b@github.com>

On Fri, 5 Aug 2022 20:26:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> Is that possible? Toolkit thread is not EDT, therefore native events are processed, it's probably enough to update the frame coordinates while EDT is blocked and doesn't handle events.
>
> Can you expand on what you mean ? 
> What's the problem with native events being processed ? We want that.
> And this obviously isn't being called on the toolkit thread.
> 
> This change isn't doing anything to that method that might change threading reqts or rules of use.
> Any problems already existed. What is being changed (apart from adding the new API) is just to make it more robust.

> The intention is that it can be called either way - on or off.

@aivanov-jdk  As @prrace mentioned, the main reason for opting - **Thread.sleep** approach instead of **robot.waitForIdle()** was to give the test user the flexibility to call `positionTestWindow` on or off EDT. (since test cases can contain either AWT or Swing components). https://github.com/openjdk/jdk/pull/9525#issuecomment-1199911675

With `waitForIdle()` approach we had to wrap parts of the code within EDT and part of it out of EDT, this was confusing and complex.

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

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


From honkar at openjdk.org  Fri Aug  5 23:50:57 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 23:50:57 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v7]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <7LseSaW3LzlWZ3gtvT061JDQMI_g72UKECV757dMfh4=.12b1775f-6560-4fcb-b2ff-d56a7a35841b@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

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

  helper method added to sync location

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/96629ad3..ccb87876

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=05-06

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

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


From honkar at openjdk.org  Fri Aug  5 23:57:13 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Aug 2022 23:57:13 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <Tz48QVf0QR46uw-D-Fc9LwhizwD3rsFa9taT4y8RVJU=.81a78f59-74fa-4771-9b7d-d0357f758ba0@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
 <Tz48QVf0QR46uw-D-Fc9LwhizwD3rsFa9taT4y8RVJU=.81a78f59-74fa-4771-9b7d-d0357f758ba0@github.com>
Message-ID: <CBY5nxv8K9Qru3sUKFukvYFfoWLm5do1r8k7qn8jWMg=.6d166a64-4540-4d35-bfc1-25285c05d726@github.com>

On Fri, 5 Aug 2022 19:37:57 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 297:
>> 
>>> 295:                 .getDefaultScreenDevice().getDefaultConfiguration();
>>> 296:         Insets screenInsets = Toolkit.getDefaultToolkit().getScreenInsets(gc);
>>> 297: 
>> 
>> I suggest separating the logic to calculate coordinates into a separate function, or save them into a local variable.
>> 
>> Then call `sync` and `sleep`. Or this sequence could be extracted into its own helper method to avoid code duplication, it's repeated at least twice.
>> 
>> Shall this method call `window.setVisible(true)` automatically?
>
> @aivanov-jdk As suggested, separating the common code into a helper method would make the code look cleaner. 
> 
> Earlier I did think about having the setVisible for both the testWindow and instruction frame within the positionWindow but usually at the test-level, the user would be in the habit of creating the testWindow and setting its visibility to true when creating test UI. Hence left it to be set at test-level. I can change it, if this approach is better.
> 
> Either way we need to make minor changes to existing manual tests - **remove** (in case we add testWindow.setVisible(true) to PassFailJFrame) or **reposition** (in case we retain it at test-level) setVisible() call.

Toolkit.sync + Thread.sleep extracted to a separate helper method.

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

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


From tr at openjdk.org  Mon Aug  8 04:13:17 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Aug 2022 04:13:17 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v7]
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9597/files
  - new: https://git.openjdk.org/jdk/pull/9597/files/53106212..7505e3f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9597&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9597&range=05-06

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

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


From duke at openjdk.org  Mon Aug  8 05:13:14 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 8 Aug 2022 05:13:14 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <elkPAk4B6beav-tlm8_RPMUCNxGVwBF9yWp9Cy4u0nU=.8b867f0d-d5ef-45dc-bdf8-643a4409e916@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
 <elkPAk4B6beav-tlm8_RPMUCNxGVwBF9yWp9Cy4u0nU=.8b867f0d-d5ef-45dc-bdf8-643a4409e916@github.com>
Message-ID: <xjz6HcBSbU9_VRiNjU3Br6TnN88r_E8f9ZMLuHua5gw=.7fe24886-8553-43d0-8c9a-cfda3ae1552d@github.com>

On Fri, 5 Aug 2022 18:58:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   creating and deleting test files dynamically
>
> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 91:
> 
>> 89:         } catch (IOException ex) {
>> 90:             throw new RuntimeException(ex);
>> 91:         }
> 
> Probably, errors during test clean-up are not as important to fail the test?

> There are many comments. Could you, @kumarabhi006, summarise the approach taken, please?

@aivanov-jdk It has been observed that the particular code segment was executing only in linux OS. So, I am converting the received file length value(long)  to a double value with one decimal point to make it similar to native OS. The conversion factor taken here is 1000 in stead of 1024, same as the native file system. The converted double value is compared with basefilesize(1000.0) and formatted as per the file size units (KB, MB, GB) using MessageFormat.

Now, the file size shown in JFileChooser is similar to native file system in linux. Only the files having size 0-999 bytes is shown as either "0 KB" or "1 KB" as we are not handling "bytes" separately.

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

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


From duke at openjdk.org  Mon Aug  8 05:21:25 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 8 Aug 2022 05:21:25 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <elkPAk4B6beav-tlm8_RPMUCNxGVwBF9yWp9Cy4u0nU=.8b867f0d-d5ef-45dc-bdf8-643a4409e916@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
 <elkPAk4B6beav-tlm8_RPMUCNxGVwBF9yWp9Cy4u0nU=.8b867f0d-d5ef-45dc-bdf8-643a4409e916@github.com>
Message-ID: <KhoFwtaf3YrXCfEPeCkPNtiJzTZLF08IIjhkI5NQMio=.d04f1604-d83c-45dd-bba9-ff601284a517@github.com>

On Fri, 5 Aug 2022 14:56:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   creating and deleting test files dynamically
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1235:
> 
>> 1233:             DecimalFormat df = new DecimalFormat("0.0");
>> 1234:             double val = len/baseFileSize;
>> 1235:             return  Double.valueOf(df.format(val));
> 
> Can we achieve the same effect without converting the value from double to string and back to double?
> 
> The returned value is `(len / 100L) / 10.0d`.

Yeah, it  can be done like this.

> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 62:
> 
>> 60:         Path dir = Paths.get(System.getProperty("test.src"));
>> 61:         String [] tempFilesName = {"2.5-KB-File","2.8-MB-File","999-KB-File","1000-KB-File","2047-Byte-File","Empty-File"};
>> 62:         int [] tempFilesSize = {2500, 2800000,999000,1000000,2047,0};
> 
> Does it make sense to sort the files by size by prefixing them? "1-Empty-File", "2-File-2047-Byte"?
> 
> Add a space after the commas.

Updated the file size string array as suggested.

> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 66:
> 
>> 64:         for (int i = 0 ; i < tempFilesName.length ; i++) {
>> 65:             tempFilePaths[i] = dir.resolve(tempFilesName[i]);
>> 66:         }
> 
> Can't the body of this for-loop be part of the next one?
> 
> There should be no space before the semi-colon.

Ok, I will make changes.

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

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


From jwaters at openjdk.org  Mon Aug  8 05:40:01 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:40:01 GMT
Subject: RFR: 8291959: FileFontStrike#initNative does not properly
 initialize IG Table on Windows [v2]
In-Reply-To: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
References: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
Message-ID: <jbjVf58GK3DXmgw0_hMPRX6HALoRJczQa4FNolDLyLs=.a401a3a7-b0af-43e2-b7ef-789e3bcd39fa@github.com>

> FileFontStrike#initNative calls memset with LCDLUTCOUNT (the maximum length) as the number of bytes to zero out, which is incorrect as the elements are not 1 byte in size (unsigned char*), and will result in only part of the IG Table being correctly zeroed. This is more correctly resolved by passing sizeof igLUTable to memset instead.

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
 - Pass proper byte size to memset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9772/files
  - new: https://git.openjdk.org/jdk/pull/9772/files/4a074c93..0d484cde

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

  Stats: 735 lines in 31 files changed: 572 ins; 37 del; 126 mod
  Patch: https://git.openjdk.org/jdk/pull/9772.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9772/head:pull/9772

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


From jwaters at openjdk.org  Mon Aug  8 05:40:02 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 8 Aug 2022 05:40:02 GMT
Subject: RFR: 8291959: FileFontStrike#initNative does not properly
 initialize IG Table on Windows
In-Reply-To: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
References: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
Message-ID: <rKvzYjdjmKquuqc6m_Pw7ty9kBsTOKH-GBpnVOLgMgE=.073c834f-d19c-4d43-8e25-fcb20b2ac42a@github.com>

On Fri, 5 Aug 2022 09:46:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> FileFontStrike#initNative calls memset with LCDLUTCOUNT (the maximum length) as the number of bytes to zero out, which is incorrect as the elements are not 1 byte in size (unsigned char*), and will result in only part of the IG Table being correctly zeroed. This is more correctly resolved by passing sizeof igLUTable to memset instead.

Bumped to latest to resolve JTReg failure on MacOS, currently awaiting sponsorship

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

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


From aturbanov at openjdk.org  Mon Aug  8 07:55:28 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 8 Aug 2022 07:55:28 GMT
Subject: RFR: 8292026: Remove redundant allocations from DoubleByteEncoder
Message-ID: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>

There are couple places where new byte array is allocated and then thrown away.

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

Commit messages:
 - [PATCH] Remove redundant allocations from DoubleByteEncoder

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

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


From duke at openjdk.org  Mon Aug  8 07:55:28 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 8 Aug 2022 07:55:28 GMT
Subject: RFR: 8292026: Remove redundant allocations from DoubleByteEncoder
In-Reply-To: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
References: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
Message-ID: <X1jPziYduS6MkBbmOyuARZojDTPmwM-ZzXhPooEVd6w=.ead2e851-a25f-4c9f-b015-d9a13c01f44e@github.com>

On Fri, 5 Aug 2022 07:07:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are couple places where new byte array is allocated and then thrown away.

Nice catch!

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

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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


From duke at openjdk.org  Mon Aug  8 10:08:08 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 8 Aug 2022 10:08:08 GMT
Subject: RFR: 8292026: Remove redundant allocations from DoubleByteEncoder
In-Reply-To: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
References: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
Message-ID: <4l2um6Qa3MrbrMv9EGxfPEvqDQVUoydt7EBrDnGR5Qw=.dd7b2b2e-cd8b-472e-ae34-cf4caaa16735@github.com>

On Fri, 5 Aug 2022 07:07:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are couple places where new byte array is allocated and then thrown away.

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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

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


From aghaisas at openjdk.org  Mon Aug  8 10:17:07 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Mon, 8 Aug 2022 10:17:07 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives [v2]
In-Reply-To: <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
 <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
Message-ID: <6dBonw1xiivUg0YkI8KMGy5ifmEPBqJmrFmwQ2dGpwM=.72ede0bc-316b-428f-8f64-a4b4063bcf42@github.com>

On Fri, 5 Aug 2022 18:01:26 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Do not cause redundant endEncoder calls with batch processing of drawing primitives
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291266: RenderPerfTest: missing content while rendering some primitives
>   
>   Added regression test

Looks good to me!

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

Marked as reviewed by aghaisas (Committer).

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


From duke at openjdk.org  Mon Aug  8 10:20:20 2022
From: duke at openjdk.org (Dio Brando)
Date: Mon, 8 Aug 2022 10:20:20 GMT
Subject: RFR: 8292026: Remove redundant allocations from DoubleByteEncoder
In-Reply-To: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
References: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
Message-ID: <4akEYJJM2a-MyQQay1Q0baC1hW-V4y3lDWUgytwRtGs=.d376dfd1-d3f7-4e03-8fe7-18c7d7255afd@github.com>

On Fri, 5 Aug 2022 07:07:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are couple places where new byte array is allocated and then thrown away.

Marked as reviewed by AJ1032480 at github.com (no known OpenJDK username).

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

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


From dnguyen at openjdk.org  Mon Aug  8 10:26:10 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 8 Aug 2022 10:26:10 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <c7wjtuN6mPqOBF16x5Ao4-uHXju0PB0Tf6cL8EFhY8E=.1c3e6ab2-9756-4d84-9e2d-0e64a9be9b05@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
 <c7wjtuN6mPqOBF16x5Ao4-uHXju0PB0Tf6cL8EFhY8E=.1c3e6ab2-9756-4d84-9e2d-0e64a9be9b05@github.com>
Message-ID: <pyqP3yzL40t81C7iWvXLlgl66wDquphSbdXGAL5fxGY=.cd200387-9bd2-4b9d-bed1-0f226e21759a@github.com>

On Thu, 14 Jul 2022 16:25:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> Can you please show before and after fix image of the editable combobox? It seems the border around the button makes it feel it's still not aligned properly which gives the impression that the button is bigger than textfield. Probably we can do away with the button border, if we can, in case we cannot draw the border around the whole textfield+button.
> 
> Also, I think if you try with different font size e.g. `comboBox.setFont(new Font("Serif", Font.PLAIN, 30));`
> 
> you will again see the editable combobox button height is not matching textfield height whereas non editable one it is aligned..

I have looked into and tested for the setFont issue for sizing editable ComboBox's in Aqua L&F. A non-editable ComboBox in Aqua does NOT increase the height of the text area of the ComboBox with larger fonts. 
Here is an image where I increased the button by 50px in height and width:
<img width="570" alt="Screen Shot 2022-08-08 at 2 04 32 AM" src="https://user-images.githubusercontent.com/96267980/183395619-e6d517f9-569b-4882-a2b0-c724a84a3e77.png">


This seems to be Aqua specific because when tested in other L&F's like Metal, the text areas and buttons increase in height to accommodate larger text. 
Here's an image from Metal L&F:
<img width="663" alt="Screen Shot 2022-08-08 at 3 20 59 AM" src="https://user-images.githubusercontent.com/96267980/183396754-fc3fbd4b-7229-4f39-9331-d415813fc3e3.png">


Additionally, the button of the ComboBox in Aqua never changes size as it seems the button appearance is pre-determined by JRS values. Increasing the size of the arrowButton in Aqua takes up the space that the enlarged button should take, but the button will still appear small.
This screenshot shows the Aqua button triggering the dropdown list after clicking the blank space where the button should be stretched to:
<img width="577" alt="Screen Shot 2022-08-08 at 2 04 48 AM" src="https://user-images.githubusercontent.com/96267980/183395864-ea860edc-8312-49b5-8d4b-346cfb593240.png">

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

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


From psadhukhan at openjdk.org  Mon Aug  8 11:38:24 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 8 Aug 2022 11:38:24 GMT
Subject: RFR: 7189422: [macosx] Submenu's arrow have a wrong position
In-Reply-To: <GifucPQelmYdGJCQToQHMSAM1qDGn8H24eCaDTxwZKA=.21cd6c4b-f919-4b3b-8b4e-098ddb473114@github.com>
References: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
 <GifucPQelmYdGJCQToQHMSAM1qDGn8H24eCaDTxwZKA=.21cd6c4b-f919-4b3b-8b4e-098ddb473114@github.com>
Message-ID: <qLFcLJqkQqcT537pHBamGZ6SdNZZQAtRJ05TSYTY7MQ=.db962fd3-5a8a-4774-aac2-4b3eabba10c0@github.com>

On Fri, 5 Aug 2022 17:34:00 GMT, Phil Race <prr at openjdk.org> wrote:

>> Issue is Arrow in submenu with empty title have a wrong position in Aqua L&F as can be seen
>> 
>> <img width="94" alt="image" src="https://user-images.githubusercontent.com/43534309/183023538-de8e51b4-31e6-45d7-b2bd-35da5e29c1e8.png">
>> 
>> 
>> which is because the text being null/empty, `labelR` rectangle width/height is 0 so arrowIcon y coordinate becomes -ve as per the calculation in layoutMenuItem(). Although it seems logical to me to not show the arrow if submenu text is null, but
>> whereas for other L&F, it is shown as this 
>> for Metal
>> <img width="83" alt="image" src="https://user-images.githubusercontent.com/43534309/183022436-d9e8ebf1-98de-4cf6-bf43-3713357846e5.png">
>> 
>> for Nimbus
>> <img width="77" alt="image" src="https://user-images.githubusercontent.com/43534309/183022730-35d170b2-71c6-4231-9a03-880107dc49c6.png">
>> 
>> so the fix is made in Aqua L&F to show as other L&F as
>> <img width="92" alt="image" src="https://user-images.githubusercontent.com/43534309/183023030-7356086d-957c-4e0d-bd52-bdf3493a96b0.png">
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaMenuPainter.java line 498:
> 
>> 496:             //    else hierRect.left = hierRect.right - w - 4;
>> 497: 
>> 498:             arrowIconR.x = Math.abs((viewR.width - arrowIconR.width) + 1);
> 
> May I take it that you verified this doesn't have any adverse effects on submenus with text :?

Yes, with fix it is
<img width="120" alt="Screenshot 2022-08-08 at 9 46 02 AM" src="https://user-images.githubusercontent.com/43534309/183338104-3df28849-1557-4c65-b22c-2f0db7ec8755.png">

whereas without fix it is
<img width="120" alt="Screenshot 2022-08-08 at 9 47 57 AM" src="https://user-images.githubusercontent.com/43534309/183338213-da66d1d5-c186-4ae2-9b14-4381df4d7dce.png">

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

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


From honkar at openjdk.org  Mon Aug  8 11:43:16 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 8 Aug 2022 11:43:16 GMT
Subject: Integrated: 8259687: JTabbedPane.setComponentAt doesn't hide
 previously visible tab component
In-Reply-To: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
References: <wlNr_5N8WHsg-CywUitXq4voWyLjkKfCZ5SyQ1O7MJA=.b176dd58-7de1-4f1f-98ca-e26ad28b014a@github.com>
Message-ID: <7mp9bhO2iMtwVd07f10qxsqrQtFMeHtCrKUwQPhYKTE=.6047b6b5-d627-4e0e-abf5-47fc947ed456@github.com>

On Thu, 28 Jul 2022 21:38:56 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> A simple change listener is used in JTabbedPane to lazily fill with components - this is done by adding the components to JTabbedPane using the `setComponentAt` in the change listener.
> 
> Previously, if the change listener was placed before calling `addTab()` , the previous visible component was overlapping with the current visible component. To fix it, the visibility of previous component is set to false before the current component's visibility is set to true in `setComponentAt`.
> 
> Following are the before and after fix screenshots-
> 
> ![image](https://user-images.githubusercontent.com/95945681/181658303-ff3a7df7-5af6-4e76-a103-45d4d76480c3.png)

This pull request has now been integrated.

Changeset: 891df212
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/891df2128ac5437af1113e83adf683bc6283b315
Stats:     112 lines in 2 files changed: 112 ins; 0 del; 0 mod

8259687: JTabbedPane.setComponentAt doesn't hide previously visible tab component

Reviewed-by: psadhukhan, dnguyen

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

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


From psadhukhan at openjdk.org  Mon Aug  8 11:44:18 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 8 Aug 2022 11:44:18 GMT
Subject: Integrated: 8064787: [macosx] In Nimbus LaF,
 Ctrl+Alt mnemonic doesn't work
In-Reply-To: <4vAsS8jNSMRplL9t7DYP3sZlYGU9VRUIk_uxSpO5JfE=.0347e9c2-4737-463e-895e-895b1c1cc613@github.com>
References: <4vAsS8jNSMRplL9t7DYP3sZlYGU9VRUIk_uxSpO5JfE=.0347e9c2-4737-463e-895e-895b1c1cc613@github.com>
Message-ID: <GdhstfoFgE9fD6BOxyqnLrPmvwrsY53FfA_MzJ6HIDM=.09e0dc13-ab61-49d8-806a-3faf025f5ec3@github.com>

On Thu, 14 Jul 2022 08:03:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In SwingSet2 application, "File" menu has a visible mnemonic set on F.
> 
> ![image](https://user-images.githubusercontent.com/43534309/178932400-ab70602a-9c4f-4cab-b3b7-0508b26d2ebe.png)
> 
> Now, in MacOS, with Aqua, Java (Metal), and Motif LaF, one can open the menu pressing Ctrl+Alt+F. 
> But with Nimbus L&F, to open File menu, you have to press Alt+F even on OS X.
> 
> It should work with Ctrl+Alt+F as sun/lwawt/macosx/LWCToolkit.java. getFocusAcceleratorKeyMask() 
> has CTRL_MASK | ALT_MASK
> 
> Fix is to add Menu.shortcutKeys in SynthLookAndFeel default table so that it can call SwingUtilities2.getSystemMnemonicKeyMask() which will call either LWCToolkit.getFocusAcceleratorKeyMask() or SunToolkit.getFocusAcceleratorKeyMask() depending on platform.
> 
> No regression test is added as it can be checked with SwingSet2 app.

This pull request has now been integrated.

Changeset: b2f0cbdc
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2f0cbdca109507e5f8e0c185f601c0c1e31f4fb
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8064787: [macosx] In Nimbus LaF, Ctrl+Alt mnemonic doesn't work

Reviewed-by: prr, dnguyen

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

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


From aivanov at openjdk.org  Mon Aug  8 11:53:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 8 Aug 2022 11:53:09 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v7]
In-Reply-To: <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
Message-ID: <uPxodpoe6KUnL0SATvFy62Iy7XOVLiHnpBjoXFHxnqI=.1b04c065-4876-47ab-83ce-997e518eb2e3@github.com>

On Mon, 8 Aug 2022 04:13:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From aivanov at openjdk.org  Mon Aug  8 11:54:05 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 8 Aug 2022 11:54:05 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <aZjyMdRQnQaMIEBk_7P8BHNNA7UK8hQ8Sz1IBxiPlVY=.f6dd46f7-6221-421c-ac90-09a23a2bfc39@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
 <EKx_2NKE01mMHILo97CURVvun_CuWTOJH9S63DXqKCM=.8751948e-3d90-488b-9f43-ba5e8822d6a0@github.com>
 <ZbahauO8GYjpIGPr3_iKcZKz0fKt8ZoYcumORI543t8=.f868066f-706a-4ee0-956e-d301e4120658@github.com>
 <aZjyMdRQnQaMIEBk_7P8BHNNA7UK8hQ8Sz1IBxiPlVY=.f6dd46f7-6221-421c-ac90-09a23a2bfc39@github.com>
Message-ID: <-lKxd9GNcFfSvi9StfGFUBWNK92z9yuGcRtPxlXTnLY=.aa9bf439-f3df-4fb7-a74d-4b31baa5af2b@github.com>

On Fri, 5 Aug 2022 20:26:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> Is that possible? Toolkit thread is not EDT, therefore native events are processed, it's probably enough to update the frame coordinates while EDT is blocked and doesn't handle events.
>
> Can you expand on what you mean ? 
> What's the problem with native events being processed ? We want that.
> And this obviously isn't being called on the toolkit thread.
> 
> This change isn't doing anything to that method that might change threading reqts or rules of use.
> Any problems already existed. What is being changed (apart from adding the new API) is just to make it more robust.

@prrace I'm just trying to understand how it works and whether it changes threading requirements. `Thread.sleep` blocks the EDT, no events are handled. If processing native events is enough to update the frame coordinates, that's good.

Thank you both for clarifying.

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

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


From psadhukhan at openjdk.org  Mon Aug  8 12:09:06 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 8 Aug 2022 12:09:06 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v9]
In-Reply-To: <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>
Message-ID: <YLHq83MSaTDynhNbwj_pj_zNYND3ZMfGhYOoBxQ7eSU=.d4eeb1b7-64f3-4b3d-b6c3-981b5f4de4d6@github.com>

On Fri, 5 Aug 2022 11:35:54 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 89:

> 87: 
> 88:         //  Creates a Graphics context when the constructor is called.
> 89:         if (graphics == null) {

Probably it will be better to use `this.graphics` here and below while setting.

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

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


From tr at openjdk.org  Mon Aug  8 15:54:31 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Aug 2022 15:54:31 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v10]
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <wzKKT6yJ9-zZXijaH8tKifNFavtENOXNeFSrHat34XQ=.68edc99e-fae9-45f4-8b77-6429e2d2933e@github.com>

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9673/files
  - new: https://git.openjdk.org/jdk/pull/9673/files/e9b164d1..cedaa2f8

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

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

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


From tr at openjdk.org  Mon Aug  8 15:54:31 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Aug 2022 15:54:31 GMT
Subject: RFR: 6521141: DebugGraphics NPE @ setFont(); [v9]
In-Reply-To: <YLHq83MSaTDynhNbwj_pj_zNYND3ZMfGhYOoBxQ7eSU=.d4eeb1b7-64f3-4b3d-b6c3-981b5f4de4d6@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
 <UgkvALP61D3k_-1DIKGOSxTsc-OvYhh-GLF4n77yQPc=.de689859-a7e8-49c9-8848-8701806cd6a2@github.com>
 <YLHq83MSaTDynhNbwj_pj_zNYND3ZMfGhYOoBxQ7eSU=.d4eeb1b7-64f3-4b3d-b6c3-981b5f4de4d6@github.com>
Message-ID: <mL7dT3exyLKhPF2ADebB0fLG50KsxTzWFBs5Uj4sxa0=.d2f84bc7-2912-4378-a97a-11f479672e5b@github.com>

On Mon, 8 Aug 2022 12:05:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated based on review comments
>
> src/java.desktop/share/classes/javax/swing/DebugGraphics.java line 89:
> 
>> 87: 
>> 88:         //  Creates a Graphics context when the constructor is called.
>> 89:         if (graphics == null) {
> 
> Probably it will be better to use `this.graphics` here and below while setting.

Updated @prsadhuk .

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

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


From honkar at openjdk.org  Mon Aug  8 18:08:29 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 8 Aug 2022 18:08:29 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v6]
In-Reply-To: <CBY5nxv8K9Qru3sUKFukvYFfoWLm5do1r8k7qn8jWMg=.6d166a64-4540-4d35-bfc1-25285c05d726@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <67yoKnvX3gXUC1lzpTaePiRdNy0cUWQWCqYK8_Jn8UU=.0d5217a1-59d4-4d2d-83d2-2ad02fe4f42a@github.com>
 <_2-2iwfBDdh93EjKpKOFPLdzJD8fDSV6yN_d0fCYuHc=.c74cd2bc-4e70-4729-9cb6-89e3680ae54d@github.com>
 <Tz48QVf0QR46uw-D-Fc9LwhizwD3rsFa9taT4y8RVJU=.81a78f59-74fa-4771-9b7d-d0357f758ba0@github.com>
 <CBY5nxv8K9Qru3sUKFukvYFfoWLm5do1r8k7qn8jWMg=.6d166a64-4540-4d35-bfc1-25285c05d726@github.com>
Message-ID: <upw7zYmCyqnsxd1PIZIPGVcT7o0_gAljnTtVwpOfoPA=.d030792f-8ad3-4851-a33f-8d513671a05b@github.com>

On Fri, 5 Aug 2022 23:55:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> @aivanov-jdk As suggested, separating the common code into a helper method would make the code look cleaner. 
>> 
>> Earlier I did think about having the setVisible for both the testWindow and instruction frame within the positionWindow but usually at the test-level, the user would be in the habit of creating the testWindow and setting its visibility to true when creating test UI. Hence left it to be set at test-level. I can change it, if this approach is better.
>> 
>> Either way we need to make minor changes to existing manual tests - **remove** (in case we add testWindow.setVisible(true) to PassFailJFrame) or **reposition** (in case we retain it at test-level) setVisible() call.
>
> Toolkit.sync + Thread.sleep extracted to a separate helper method.

> Earlier I did think about having the setVisible for both the testWindow and instruction frame within the positionWindow but usually at the test-level, the user would be in the habit of creating the testWindow and setting its visibility to true when creating test UI. Hence left it to be set at test-level. I can change it, if this approach is better.
> 
> Either way we need to make minor changes to existing manual tests - **remove** (in case we add testWindow.setVisible(true) to PassFailJFrame) or **reposition** (in case we retain it at test-level) setVisible() call.

@aivanov-jdk I have retained  `setVisible()` for testWindow on test side (where test UI is created) for reasons as described above. Please let me know in case it is better to have it within `positionWindow()`.

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

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


From serb at openjdk.org  Mon Aug  8 21:55:02 2022
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 8 Aug 2022 21:55:02 GMT
Subject: Integrated: 8288633: The ICC_ColorSpace.fromCIEXYZ method uses the
 wrong rendering intent
In-Reply-To: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
References: <AprfDeGGekE6v7_zvFM4-HP6mlJnsl7ORj35pSVcbIM=.414a77f0-99db-4535-8bfe-94c77418aeb6@github.com>
Message-ID: <kltC_VNN9RakPYxrmdwUmkiP5R2qJ_2mOSH1qoDr5ik=.b3bc1fa3-96bf-4ecf-be53-c3979fae84c0@github.com>

On Fri, 17 Jun 2022 00:09:28 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The specification of the  ICC_ColorSpace.fromCIEXYZ method [says](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L428):
> 
>> * This method transforms color values using relative colorimetry, as defined by the ICC Specification.
> 
> The LCMS plugin implementation expects the rendering intent in the first part of transform:
> https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L116
> 
> But the ICC_ColorSpace.fromCIEXYZ pass "ICC_Profile.icRelativeColorimetric" to the [second ](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L534) part of transform. 
> 
> Note that ICC_ColorSpace.toCIEXYZ has a similar [specification ](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L288)is implemented [properly](https://github.com/openjdk/jdk/blob/9d4b25e7888098a866ff980e37b8d16d456906d8/src/java.desktop/share/classes/java/awt/color/ICC_ColorSpace.java#L391).

This pull request has now been integrated.

Changeset: 77398430
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/77398430b5e13768cddd5f63e8fe9e53735bbea8
Stats:     102 lines in 2 files changed: 95 ins; 2 del; 5 mod

8288633: The ICC_ColorSpace.fromCIEXYZ method uses the wrong rendering intent

Reviewed-by: prr

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

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


From info at scientificware.com  Tue Aug  9 11:33:00 2022
From: info at scientificware.com (info at scientificware.com)
Date: Tue, 09 Aug 2022 13:33:00 +0200
Subject: client-libs-dev Digest, Vol 13, Issue 86
In-Reply-To: <mailman.2350.1658945623.391.client-libs-dev@openjdk.org>
References: <mailman.2350.1658945623.391.client-libs-dev@openjdk.org>
Message-ID: <b0c84d384202daa6056241e0c4e3c51b@scientificware.com>

Hello,
Could someone explain what means the label "dcspn" in the JDK Bug 
System.
Regards.


From psadhukhan at openjdk.org  Tue Aug  9 11:55:58 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Aug 2022 11:55:58 GMT
Subject: RFR: 8292062: misc javax/swing tests failing
Message-ID: <wiXsnS5Kgj62F0A6ve80XIuPWh2p9PYE6hU3I2D7yV0=.748cf5aa-c32f-45f3-af2e-f24b134351aa@github.com>

In [PR#9488](https://github.com/openjdk/jdk/pull/9488) https://git.openjdk.org/jdk/commit/b2f0cbdca109507e5f8e0c185f601c0c1e31f4fb
`CTRL+ALT` mnemonic support was added for Nimbus in macOS instead of `Alt`

so 2 of the 3 tests were failing after that, as it has workaround for non-support of CTRL+ALT mnemonic in macos for Nimbus L&F.
That workaround is now removed for the tests to now pass.

For RightAltKey test failure, we should have ALT_GRAPH mask for Menu.shortcutKeys also,
 as it is done for
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1101

so ALT_GRAPH support was added for Nimbus Menu.shortcutKeys

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

Commit messages:
 - 8292062: misc javax/swing tests failing

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

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


From tr at openjdk.org  Tue Aug  9 11:56:58 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 9 Aug 2022 11:56:58 GMT
Subject: Integrated: 8290278: JavaDoc of index parameter of method
 JTabbedPane.insertTab
In-Reply-To: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
References: <Q3-D1QrwoSA_yrfPRfjCSNw--95J_FEN7_nKeY8rIsQ=.e94b1228-6701-4590-89b5-adec1a9238de@github.com>
Message-ID: <LxHmOoNv655Pj4Q1f2L3FLHCHnZaTFqS81iI0rDsGME=.76db3768-ea0b-412b-b5f0-f020d886e388@github.com>

On Thu, 14 Jul 2022 15:58:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> JavaDoc of _JTabbedPane.inseetTab()_ is updated. The index position to insert a new tab ranges from 0 to _TabCount_(Position after the last tab position), the same is updated from _> 0_ to _>= 0_ .

This pull request has now been integrated.

Changeset: cbc9040f
Author:    Tejesh R <tr at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbc9040f3a3a86942fa8277860eedc1f5142b64b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8290278: JavaDoc of index parameter of method JTabbedPane.insertTab

Reviewed-by: psadhukhan, prr, honkar

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

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


From psadhukhan at openjdk.org  Tue Aug  9 12:20:36 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 9 Aug 2022 12:20:36 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v7]
In-Reply-To: <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
Message-ID: <rfOb-bwv0JPTlxtcBSBY3WzCMqCAoEcFHpSIZ30LI5s=.4ee1e65d-8cf1-43fb-9067-829a071a35f6@github.com>

On Mon, 8 Aug 2022 04:13:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Since JBS says the problem is seen when "L&F used is Nimbus "
and you made changes in BasicFileChooserUI which will affect all L&F, please confirm that it is working for all L&F in windows (Metal, Nimbus, Windows, WindowsClassic)

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

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


From duke at openjdk.org  Tue Aug  9 12:31:19 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 9 Aug 2022 12:31:19 GMT
Subject: Integrated: 6391806: JLabel and AbstractButton's imageUpdate method
 should be better specified
In-Reply-To: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
References: <tjvSQv10MR612ASAOiox4WbsVjAA6W49SstHrptZNRw=.8f60d8e5-493b-4c74-a4b3-d0b86977f9d6@github.com>
Message-ID: <NsWzht8dI0lRrHcQXkh0_aRVKFsQDSSlW3tg-vJB4BI=.c65c9dcf-c8dc-4478-a39f-6a669ef6d651@github.com>

On Wed, 22 Jun 2022 13:14:31 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> JLabel and AbstractButton's imageUpdate method description updated.

This pull request has now been integrated.

Changeset: 3677b55b
Author:    Abhishek Kumar <abhishek.cx.kumar at oracle.com>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3677b55b45746c3c955a8fcf1fbbf15694baa873
Stats:     17 lines in 2 files changed: 11 ins; 0 del; 6 mod

6391806: JLabel and AbstractButton's imageUpdate method should be better specified

Reviewed-by: psadhukhan, prr

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

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


From duke at openjdk.org  Tue Aug  9 13:32:09 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 9 Aug 2022 13:32:09 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

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

  suggested review comments updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/084a82a7..45d017ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=13-14

  Stats: 95 lines in 2 files changed: 46 ins; 19 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

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


From duke at openjdk.org  Tue Aug  9 13:34:53 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 9 Aug 2022 13:34:53 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v14]
In-Reply-To: <uMedHsG6u8DhfYpNS6Dsf7ZIJ8orstwrtnIBe2PPl5A=.b8802967-853f-4424-994f-338967f66151@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <IXda_j-3ttBkaynTTHpBhLdCgc21l4Ri8tgQlDo4AqI=.c8d250f0-7fc5-4d43-999f-7a2344992d0b@github.com>
 <uMedHsG6u8DhfYpNS6Dsf7ZIJ8orstwrtnIBe2PPl5A=.b8802967-853f-4424-994f-338967f66151@github.com>
Message-ID: <YaAC754w8jbIIY0cMf_eSUb_UcwyIka6bRJXoG8r3q4=.1ef2e88b-5975-4c1c-b907-77fa208dbcc0@github.com>

On Fri, 5 Aug 2022 19:04:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   creating and deleting test files dynamically
>
> Does the size formatting respect the user's setting for the decimal symbol?

@aivanov-jdk I have updated the suggested changes. JFileChooser has been added as a component in frame.

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

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


From duke at openjdk.org  Tue Aug  9 13:40:51 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Tue, 9 Aug 2022 13:40:51 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
Message-ID: <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>

On Tue, 9 Aug 2022 13:32:09 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested review comments updated

@prsadhuk I have made few changes in formatting the file size, using MessageFormat and NumberFormat to format the file size with 1 decimal place precision. Earlier JFileChooser  show file size for "1.0" as "1", now it will show one decimal place precision. Empty files show as "0 KB".

![1_Decimal_Precision](https://user-images.githubusercontent.com/107542245/183662527-61c4ba88-5955-4958-9aa9-d45eb61eb710.png)

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

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


From tr at openjdk.org  Tue Aug  9 15:05:22 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 9 Aug 2022 15:05:22 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v7]
In-Reply-To: <rfOb-bwv0JPTlxtcBSBY3WzCMqCAoEcFHpSIZ30LI5s=.4ee1e65d-8cf1-43fb-9067-829a071a35f6@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
 <rfOb-bwv0JPTlxtcBSBY3WzCMqCAoEcFHpSIZ30LI5s=.4ee1e65d-8cf1-43fb-9067-829a071a35f6@github.com>
Message-ID: <R4JYjwQfcdAxj-TwQOs5VePcuzF-FBkTk9FKnoXdOeo=.adde936b-e6ae-4949-8a23-f5b5752c05a8@github.com>

On Tue, 9 Aug 2022 12:18:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since JBS says the problem is seen when "L&F used is Nimbus " and you made changes in BasicFileChooserUI which will affect all L&F, please confirm that it is working for all L&F in windows (Metal, Nimbus, Windows, WindowsClassic)

Yeah sure, will check again with other L&F and confirm.

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

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


From prr at openjdk.org  Tue Aug  9 15:17:37 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Aug 2022 15:17:37 GMT
Subject: RFR: 8292062: misc javax/swing tests failing
In-Reply-To: <wiXsnS5Kgj62F0A6ve80XIuPWh2p9PYE6hU3I2D7yV0=.748cf5aa-c32f-45f3-af2e-f24b134351aa@github.com>
References: <wiXsnS5Kgj62F0A6ve80XIuPWh2p9PYE6hU3I2D7yV0=.748cf5aa-c32f-45f3-af2e-f24b134351aa@github.com>
Message-ID: <qbBfh6T3Tdpjb_YaqJ7nHNkixUBIfsNjGKql4TRc4r8=.b8b79b70-2340-4146-b67f-2dfa84b6710b@github.com>

On Tue, 9 Aug 2022 11:49:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In [PR#9488](https://github.com/openjdk/jdk/pull/9488) https://git.openjdk.org/jdk/commit/b2f0cbdca109507e5f8e0c185f601c0c1e31f4fb
> `CTRL+ALT` mnemonic support was added for Nimbus in macOS instead of `Alt`
> 
> so 2 of the 3 tests were failing after that, as it has workaround for non-support of CTRL+ALT mnemonic in macos for Nimbus L&F.
> That workaround is now removed for the tests to now pass.
> 
> For RightAltKey test failure, we should have ALT_GRAPH mask for Menu.shortcutKeys also,
>  as it is done for
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1101
> 
> so ALT_GRAPH support was added for Nimbus Menu.shortcutKeys

Since there is a JDK source code change in this proposal, please confirm you have run ALL automated tests on ALL platforms.
Not just a subset.

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

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


From dcubed at openjdk.org  Tue Aug  9 18:20:31 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 9 Aug 2022 18:20:31 GMT
Subject: RFR: 8292119: ProblemList
 java/awt/image/multiresolution/MultiresolutionIconTest.java on linux-x64 and
 windows-all
Message-ID: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>

A trivial fix to ProblemList java/awt/image/multiresolution/MultiresolutionIconTest.java
on linux-x64 and windows-all

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

Commit messages:
 - 8292119: ProblemList java/awt/image/multiresolution/MultiresolutionIconTest.java on linux-x64 and windows-all

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

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


From naoto at openjdk.org  Tue Aug  9 18:20:32 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Aug 2022 18:20:32 GMT
Subject: RFR: 8292119: ProblemList
 java/awt/image/multiresolution/MultiresolutionIconTest.java on linux-x64 and
 windows-all
In-Reply-To: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>
References: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>
Message-ID: <ubVVJPIznEjWsdn9kMVLUUjdr3auEuWFYuo_D4oHb5c=.0899b26e-db60-4748-a843-0bffe538d6bc@github.com>

On Tue, 9 Aug 2022 17:35:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/image/multiresolution/MultiresolutionIconTest.java
> on linux-x64 and windows-all

Marked as reviewed by naoto (Reviewer).

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

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


From prr at openjdk.org  Tue Aug  9 18:45:06 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Aug 2022 18:45:06 GMT
Subject: RFR: 8292119: ProblemList
 java/awt/image/multiresolution/MultiresolutionIconTest.java on linux-x64 and
 windows-all
In-Reply-To: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>
References: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>
Message-ID: <jcsfQgYWL5P_FlshfKFWyqdqor3hQO5OrgrJ1g_TSsU=.c9ce56ff-8575-4f6e-97d5-6a844d62c467@github.com>

On Tue, 9 Aug 2022 17:35:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/image/multiresolution/MultiresolutionIconTest.java
> on linux-x64 and windows-all

Marked as reviewed by prr (Reviewer).

was it problem listed on windows before ?

ah yes it was

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

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


From dcubed at openjdk.org  Tue Aug  9 18:54:10 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 9 Aug 2022 18:54:10 GMT
Subject: RFR: 8292119: ProblemList
 java/awt/image/multiresolution/MultiresolutionIconTest.java on linux-x64 and
 windows-all
In-Reply-To: <ubVVJPIznEjWsdn9kMVLUUjdr3auEuWFYuo_D4oHb5c=.0899b26e-db60-4748-a843-0bffe538d6bc@github.com>
References: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>
 <ubVVJPIznEjWsdn9kMVLUUjdr3auEuWFYuo_D4oHb5c=.0899b26e-db60-4748-a843-0bffe538d6bc@github.com>
Message-ID: <DtbtpmFsAp4O9lgQlTOmqcpSL5IHXoPwWPwHHALB2lg=.1a811321-1b9f-4cc2-a954-b12358d41257@github.com>

On Tue, 9 Aug 2022 17:43:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> A trivial fix to ProblemList java/awt/image/multiresolution/MultiresolutionIconTest.java
>> on linux-x64 and windows-all
>
> Marked as reviewed by naoto (Reviewer).

@naotoj and @prrace - Thanks for the reviews.

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

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


From dcubed at openjdk.org  Tue Aug  9 18:54:10 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Tue, 9 Aug 2022 18:54:10 GMT
Subject: Integrated: 8292119: ProblemList
 java/awt/image/multiresolution/MultiresolutionIconTest.java on linux-x64 and
 windows-all
In-Reply-To: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>
References: <02aXBtY4-b72eg_4G1kt4kUXki8QVt-s9OK8NBPUvPI=.892b2400-fbd3-4a9c-8575-09921321e797@github.com>
Message-ID: <bKw_cBpJh2_BfEsi6K4bKVWinUqcIXc2-2vOX9FtKIg=.c7fe0ac0-e8f1-483b-9fd9-449e4fa8bc75@github.com>

On Tue, 9 Aug 2022 17:35:24 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/awt/image/multiresolution/MultiresolutionIconTest.java
> on linux-x64 and windows-all

This pull request has now been integrated.

Changeset: 17c77b5d
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17c77b5d7a25d6e8e127a2559b8f661c743701c1
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8292119: ProblemList java/awt/image/multiresolution/MultiresolutionIconTest.java on linux-x64 and windows-all

Reviewed-by: naoto, prr

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

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


From tr at openjdk.org  Tue Aug  9 18:59:48 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 9 Aug 2022 18:59:48 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v7]
In-Reply-To: <R4JYjwQfcdAxj-TwQOs5VePcuzF-FBkTk9FKnoXdOeo=.adde936b-e6ae-4949-8a23-f5b5752c05a8@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
 <rfOb-bwv0JPTlxtcBSBY3WzCMqCAoEcFHpSIZ30LI5s=.4ee1e65d-8cf1-43fb-9067-829a071a35f6@github.com>
 <R4JYjwQfcdAxj-TwQOs5VePcuzF-FBkTk9FKnoXdOeo=.adde936b-e6ae-4949-8a23-f5b5752c05a8@github.com>
Message-ID: <E5tu_rZS-skz1PORapDFb1aGUzHuk50GvuP-O9auDOs=.493375ce-babc-458e-8331-5bf2fcedb240@github.com>

On Tue, 9 Aug 2022 15:01:48 GMT, Tejesh R <tr at openjdk.org> wrote:

> Since JBS says the problem is seen when "L&F used is Nimbus " and you made changes in BasicFileChooserUI which will affect all L&F, please confirm that it is working for all L&F in windows (Metal, Nimbus, Windows, WindowsClassic)

@prsadhuk I've checked for the mentioned L&F and its working fine.

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

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


From prr at openjdk.org  Tue Aug  9 19:25:46 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Aug 2022 19:25:46 GMT
Subject: RFR: 8292062: misc javax/swing tests failing
In-Reply-To: <wiXsnS5Kgj62F0A6ve80XIuPWh2p9PYE6hU3I2D7yV0=.748cf5aa-c32f-45f3-af2e-f24b134351aa@github.com>
References: <wiXsnS5Kgj62F0A6ve80XIuPWh2p9PYE6hU3I2D7yV0=.748cf5aa-c32f-45f3-af2e-f24b134351aa@github.com>
Message-ID: <WDk7CtkPaOsxp8ObKxzwdGAFqmXMIo2PB4u1lmHGl80=.9adee52f-7b09-466c-a0bf-7e0376fc9951@github.com>

On Tue, 9 Aug 2022 11:49:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In [PR#9488](https://github.com/openjdk/jdk/pull/9488) https://git.openjdk.org/jdk/commit/b2f0cbdca109507e5f8e0c185f601c0c1e31f4fb
> `CTRL+ALT` mnemonic support was added for Nimbus in macOS instead of `Alt`
> 
> so 2 of the 3 tests were failing after that, as it has workaround for non-support of CTRL+ALT mnemonic in macos for Nimbus L&F.
> That workaround is now removed for the tests to now pass.
> 
> For RightAltKey test failure, we should have ALT_GRAPH mask for Menu.shortcutKeys also,
>  as it is done for
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1101
> 
> so ALT_GRAPH support was added for Nimbus Menu.shortcutKeys

OK approved based on fuller test results

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

Marked as reviewed by prr (Reviewer).

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


From aivanov at openjdk.org  Tue Aug  9 19:24:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Aug 2022 19:24:42 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
Message-ID: <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>

On Tue, 9 Aug 2022 13:38:22 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> @prsadhuk I have made few changes in formatting the file size, using MessageFormat and NumberFormat to format the file size with 1 decimal place precision. Earlier JFileChooser show file size for "1.0" as "1", now it will show one decimal place precision. Empty files show as "0 KB".

If JFileChooser always shows a decimal point for nearly all files, should it show 0.0 KB for zero-sized files?

I guess it would simplify your code as there'll be no reason to change number format.

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

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


From aivanov at openjdk.org  Tue Aug  9 19:35:59 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Aug 2022 19:35:59 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
Message-ID: <yp1uIVHSY22Vb0jI-Jp7pe4L0j59CrAOITLoQr8NHPk=.3f50da5f-398b-464c-95d3-b03c6cbcf09e@github.com>

On Tue, 9 Aug 2022 13:32:09 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested review comments updated

src/java.desktop/share/classes/sun/swing/FilePane.java line 1202:

> 1200:                         updateMessageFormatPattern(kiloByteString,0);
> 1201:                     } else {
> 1202:                         updateMessageFormatPattern(kiloByteString,1);

There should a space after comma.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1256:

> 1254:             mf.setFormat(0, nf);
> 1255:         }
> 1256:         private double formatToDoubleValue(long len) {

Should be static.

Please add a blank line between the methods.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 66:

> 64:         fc = new JFileChooser();
> 65:         Path dir = Paths.get(System.getProperty("test.src"));
> 66:         String [] tempFilesName = {"1-Empty-File", "2-File-2047-Byte", "3-File-2.5-KB", "4-File-999-KB", "5-File-1000-KB", "6-File-2.8-MB"};

Please break the long line. It's a common practice to code into 80 columns, or 100 at maximum. This line has 140 columns.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 67:

> 65:         Path dir = Paths.get(System.getProperty("test.src"));
> 66:         String [] tempFilesName = {"1-Empty-File", "2-File-2047-Byte", "3-File-2.5-KB", "4-File-999-KB", "5-File-1000-KB", "6-File-2.8-MB"};
> 67:         int [] tempFilesSize = {0, 2047, 2500, 999000, 1000000, 2800000};

Hint: You can use `_` as a group separator in numeric literals: 1_000_000 is more readable.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 93:

> 91: 
> 92:     public static void main(String args[]) throws InterruptedException, InvocationTargetException {
> 93:         passFailJFrame = new PassFailJFrame("JFileChooser Test Instructions" , INSTRUCTIONS, 5, 19, 35);

This line should also be wrapped; wrapping after the first parameter looked better.

(There should be no space before the comma in the argument list.)

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 99:

> 97:                     test();
> 98:                 }
> 99:             });

I suggest using method reference:

Suggestion:

            SwingUtilities.invokeAndWait(FileSizeCheck::test);

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

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


From prr at openjdk.org  Tue Aug  9 22:47:32 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Aug 2022 22:47:32 GMT
Subject: RFR: 8292026: Remove redundant allocations from DoubleByteEncoder
In-Reply-To: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
References: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
Message-ID: <QE_VGQONBKFvGrr63ffeOIpP_iaC-T_z6z823rEopek=.9293ef66-1758-48a3-be8f-4a28de20ab5c@github.com>

On Fri, 5 Aug 2022 07:07:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are couple places where new byte array is allocated and then thrown away.

I suspect that once upon a time that was passed in as an arg to be populated .. but the code changed.

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

Marked as reviewed by prr (Reviewer).

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


From mickleness at gmail.com  Wed Aug 10 02:12:57 2022
From: mickleness at gmail.com (Jeremy Wood)
Date: Wed, 10 Aug 2022 02:12:57 +0000
Subject: Mac Tray Icon Question
Message-ID: <em32971c20-730c-4b57-b1cd-5a35ee11227d@573fd4be.com>

On Macs the tray can present black or white icons, depending on the 
color of the desktop underneath the menubar.

For example:



Most icons switch from a black icon to a white icon as needed. A few 3rd 
party app icons do not switch to a white icon against the black 
background (for ex: Evernote). And interestingly: Apple?s Airdrop icon 
(the concentric circles shaped like a sideways pacman) also appears to 
do the wrong thing too.

Is there a way in a Java desktop app to set up a tray icon that can 
toggle between white and black icons as needed?

Obviously we?d love it if this ?just worked? without further 
intervention by inverting our icon, but we?d also be happy if a solution 
involved adding a PropertyChangeListener somewhere to identify the 
menubar change and we could update the tray icons ourselves.

For ex:
If I change the highlight/accent color (in ?System Preferences -> 
General?), then 8 UIManager Colors change (including ?textHighlight?, 
?Button.light?, etc.) as of JDK 18. As far as I can tell: there is no 
similar model to identify when the menubar changes colors.

For now we?ve made a work-around by using the Robot class to grab a 
pixel from the Apple menu icon every few seconds to determine if it?s 
light or dark.

Is there an existing way to resolve this we don?t know about?

Or if not: is anyone reading this with ?author? status interested in 
helping write this up as an openjdk bug?

Regards,
  - Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/084dbe07/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: galpmnvf.png
Type: image/png
Size: 12001 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/084dbe07/galpmnvf.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtqoidmn.png
Type: image/png
Size: 10952 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/084dbe07/qtqoidmn.png>

From psadhukhan at openjdk.org  Wed Aug 10 03:44:42 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Aug 2022 03:44:42 GMT
Subject: Integrated: 8292062: misc javax/swing tests failing
In-Reply-To: <wiXsnS5Kgj62F0A6ve80XIuPWh2p9PYE6hU3I2D7yV0=.748cf5aa-c32f-45f3-af2e-f24b134351aa@github.com>
References: <wiXsnS5Kgj62F0A6ve80XIuPWh2p9PYE6hU3I2D7yV0=.748cf5aa-c32f-45f3-af2e-f24b134351aa@github.com>
Message-ID: <8TPtPp9FLU-oznHKgnDYXbmGhqkVCaYVN8WZC4EvdEI=.248a883f-d51b-4aab-abad-202fb8167955@github.com>

On Tue, 9 Aug 2022 11:49:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> In [PR#9488](https://github.com/openjdk/jdk/pull/9488) https://git.openjdk.org/jdk/commit/b2f0cbdca109507e5f8e0c185f601c0c1e31f4fb
> `CTRL+ALT` mnemonic support was added for Nimbus in macOS instead of `Alt`
> 
> so 2 of the 3 tests were failing after that, as it has workaround for non-support of CTRL+ALT mnemonic in macos for Nimbus L&F.
> That workaround is now removed for the tests to now pass.
> 
> For RightAltKey test failure, we should have ALT_GRAPH mask for Menu.shortcutKeys also,
>  as it is done for
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java#L1101
> 
> so ALT_GRAPH support was added for Nimbus Menu.shortcutKeys

This pull request has now been integrated.

Changeset: 83dc2e3e
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83dc2e3e45a946dd1302efb84baf3afaa9309ba4
Stats:     9 lines in 4 files changed: 2 ins; 0 del; 7 mod

8292062: misc javax/swing tests failing

Reviewed-by: prr

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

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


From psadhukhan at openjdk.org  Wed Aug 10 04:00:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Aug 2022 04:00:38 GMT
Subject: RFR: 8281966: Absolute path of symlink is null in JFileChooser
 [v7]
In-Reply-To: <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
 <Wlad49jH2QcF2NMesfLlKyuYkr7ZHgt2Zr6thjQPOJw=.b7c49339-f709-4129-a964-cf757fc8f370@github.com>
Message-ID: <kjyziXKuG1-1W_TZ4XkHSvg6tEyTDmx8lYOD_bj2Mbk=.dfdbfd8c-8823-45c8-ab59-bf1fc07cf9a7@github.com>

On Mon, 8 Aug 2022 04:13:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by psadhukhan (Reviewer).

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

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


From duke at openjdk.org  Wed Aug 10 04:51:44 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Aug 2022 04:51:44 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
 <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
Message-ID: <sOUOMvWHnERHCIFxDaSR4U_66fGIceUTtv8rnMsPAvo=.305be23c-30e0-4ab8-a1db-93fd0ccdc313@github.com>

On Tue, 9 Aug 2022 19:21:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > @prsadhuk I have made few changes in formatting the file size, using MessageFormat and NumberFormat to format the file size with 1 decimal place precision. Earlier JFileChooser show file size for "1.0" as "1", now it will show one decimal place precision. Empty files show as "0 KB".
> 
> If JFileChooser always shows a decimal point for nearly all files, should it show 0.0 KB for zero-sized files?
> 
> I guess it would simplify your code as there'll be no reason to change number format.

@aivanov-jdk  It will simplify the code but I checked in native file system and it shows "0 bytes" for zero-sized files. So to keep it similar to native, zero-sized files shown as "0 KB".

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

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


From darcy at openjdk.org  Wed Aug 10 05:14:39 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Aug 2022 05:14:39 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <9WNf2Wy1unVHYw14y1oMrFgsLvHW2jkj7XXXSDB8PbA=.fbffd896-f46c-41ee-90d8-06e414bcafbe@github.com>

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

src/java.desktop/share/classes/java/awt/geom/AffineTransform.java line 3920:

> 3918:     private static long hash(double m) {
> 3919:         long h = Double.doubleToLongBits(m);
> 3920:         if (h == 0x8000000000000000L) h = 0;    // Replace -0 by +0.

Another idiom to accomplish this is 

return Double.doubleToLongBits(m + 0.0); // Turn -0.0 to +0.0

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

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


From darcy at openjdk.org  Wed Aug 10 05:29:44 2022
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 10 Aug 2022 05:29:44 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <2bez2JZQKhsHEuZK4fLIZDOoHwFObNUsxmP4tJ5Y9H0=.acdd9bd6-dc89-4731-b082-4e2f35f3bd2e@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
 <2bez2JZQKhsHEuZK4fLIZDOoHwFObNUsxmP4tJ5Y9H0=.acdd9bd6-dc89-4731-b082-4e2f35f3bd2e@github.com>
Message-ID: <wuT6XIffZ7fPDJ5-V1uQZJHm5NgCTcgWXi1gyjFOIGA=.378b9163-9f61-4ec3-b7d2-b150ffaf5e23@github.com>

On Thu, 4 Aug 2022 22:21:19 GMT, Phil Race <prr at openjdk.org> wrote:

> I've run all tests we have and not too surprised they pass since the affected values probably aren't being exercised.
> 
> However I've been reading the docs about NaN and +/-0 equivalence at https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Double.html since if we change anything it probably ought to align with what ever says there.
> 
> Since I recalled that NaN == NaN will always return false, it seemed what you have was not consistent with that. Whilst this is true it seems Double.equals() does the opposite .. so OK .. although it surprised me.
> 
> But then the docs say +0 and -0 should not be equal whereas for backwards compatibility you say you extended them being treated as equal from equals() into hashCode() ..
> 
> Not sure why only in this case was the compatibility important.
> 
> I'd like to hear what @jddarcy (Joe Darcy) thinks about all of this.

For the equals contract, members of an equivalence class should all be equal to each other, meaning they are substitutable for each other in some sense. Different equivalence classes can be defined for the same set of values, one notable example being == (object identity) versus calling .equals().

>From my reading of AffineTransform, it should be an acceptable substitution to use -0.0 rather +0.0. As noted a NaN value is "the same" as another NaN in the sense being tested in this method.

One way to express this would be to define

private static boolean equiv(double a, double b) {
    return Double.compare(a + 0.0, b + 0.0);
}

Adding 0.0 turn -0.0 into +0.0 and has no other effect. Double.compare treats NaN inputs as the same. This could then do pair-wise comparison of the various components, 

return equiv(m00, a.m00) && equiv(m01, a.m01) && ...

If this is the equals function, than the hash can be a combination of

Double.doubleToLongBits(m01 +0.0) ...

using adding 0.0 adding to remove the case of -0.0. As is already being done, using doubleToLongBits instead of doubleToRawLongBits is important so that all NaN values get mapped the same.

A different equals and hashCode could be constructed if all 90 degree rotations (of the same length) were considered the same, but that would require more work to construct.

HTH

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

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


From duke at openjdk.org  Wed Aug 10 05:30:56 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Aug 2022 05:30:56 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

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

  updated as per  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/45d017ed..e699f033

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=14-15

  Stats: 24 lines in 2 files changed: 5 ins; 4 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

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


From duke at openjdk.org  Wed Aug 10 05:30:57 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Aug 2022 05:30:57 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
 <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
Message-ID: <pMu2EGFmWiRL-_m9q8He6P4ShwCp2BbH2Of4PtmpymY=.54ed09be-c55e-4c50-b914-0a1a943af6ce@github.com>

On Tue, 9 Aug 2022 19:21:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @prsadhuk I have made few changes in formatting the file size, using MessageFormat and NumberFormat to format the file size with 1 decimal place precision. Earlier JFileChooser  show file size for "1.0" as "1", now it will show one decimal place precision. Empty files show as "0 KB".
>> 
>> ![1_Decimal_Precision](https://user-images.githubusercontent.com/107542245/183662527-61c4ba88-5955-4958-9aa9-d45eb61eb710.png)
>
>> @prsadhuk I have made few changes in formatting the file size, using MessageFormat and NumberFormat to format the file size with 1 decimal place precision. Earlier JFileChooser show file size for "1.0" as "1", now it will show one decimal place precision. Empty files show as "0 KB".
> 
> If JFileChooser always shows a decimal point for nearly all files, should it show 0.0 KB for zero-sized files?
> 
> I guess it would simplify your code as there'll be no reason to change number format.

@aivanov-jdk I have updated as per the suggested changes.

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

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


From duke at openjdk.org  Wed Aug 10 05:55:09 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Aug 2022 05:55:09 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <yp1uIVHSY22Vb0jI-Jp7pe4L0j59CrAOITLoQr8NHPk=.3f50da5f-398b-464c-95d3-b03c6cbcf09e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <yp1uIVHSY22Vb0jI-Jp7pe4L0j59CrAOITLoQr8NHPk=.3f50da5f-398b-464c-95d3-b03c6cbcf09e@github.com>
Message-ID: <Ry6DFFKLZKL_z5wR45lsmWm8qoyq8IxVLWmluUFdvhw=.7a924d89-081e-4d5d-a7b0-be664ff1993d@github.com>

On Tue, 9 Aug 2022 19:02:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   suggested review comments updated
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1202:
> 
>> 1200:                         updateMessageFormatPattern(kiloByteString,0);
>> 1201:                     } else {
>> 1202:                         updateMessageFormatPattern(kiloByteString,1);
> 
> There should a space after comma.

implemented the suggested change.

> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 67:
> 
>> 65:         Path dir = Paths.get(System.getProperty("test.src"));
>> 66:         String [] tempFilesName = {"1-Empty-File", "2-File-2047-Byte", "3-File-2.5-KB", "4-File-999-KB", "5-File-1000-KB", "6-File-2.8-MB"};
>> 67:         int [] tempFilesSize = {0, 2047, 2500, 999000, 1000000, 2800000};
> 
> Hint: You can use `_` as a group separator in numeric literals: 1_000_000 is more readable.

Sure, I have implemented the suggested change.

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

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


From tr at openjdk.org  Wed Aug 10 11:46:22 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Aug 2022 11:46:22 GMT
Subject: Integrated: 8281966: Absolute path of symlink is null in JFileChooser
In-Reply-To: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
References: <NSaJEZnM7ULp6o_ME24qaYjyDVQEOmJBwtP98eDyFlY=.fb36af00-d550-4314-a5a6-6f6dedd06211@github.com>
Message-ID: <jJWsCm57nUFrJgipSRQXKg7Dtt1ssixH1JIco0q4EE0=.13413ed6-aa25-413d-89e0-a84a5dd46df0@github.com>

On Thu, 21 Jul 2022 18:31:46 GMT, Tejesh R <tr at openjdk.org> wrote:

> Absolute path of Symbolic Link created in Windows is set to `null` in `BasicFileChooserUI` class. This happens when propertyChangeListener is implemented to get the Symbolic link's Absolute path on Mouse click through JFileChooser. The reason being that on click of Symbolic link, the _ValueChanged()_ in `BasicFileChooserUI` class has a logic which actually sets the  `chooser.SelectedFile()` to `null` even though the path is not null. Hence the issue is addressed by checking if its a Symbolic link and then setting the `chooser.SelectedFile()` to the value of clicked link without modifying the other logics.

This pull request has now been integrated.

Changeset: ecfa38ff
Author:    Tejesh R <tr at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ecfa38ffa8620e41854a043497f19863da297947
Stats:     169 lines in 2 files changed: 165 ins; 0 del; 4 mod

8281966: Absolute path of symlink is null in JFileChooser

Reviewed-by: aivanov, psadhukhan

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

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


From javalists at cbfiddle.com  Wed Aug 10 12:25:11 2022
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 10 Aug 2022 05:25:11 -0700
Subject: Mac Tray Icon Question
In-Reply-To: <em32971c20-730c-4b57-b1cd-5a35ee11227d@573fd4be.com>
References: <em32971c20-730c-4b57-b1cd-5a35ee11227d@573fd4be.com>
Message-ID: <A481B3B7-1AEC-4B5C-AEF9-92C41F5E8A63@cbfiddle.com>

I suspect the images that work are template images, rather than pairs of images.

See https://developer.apple.com/documentation/appkit/nsimage/1520017-template



> On Aug 9, 2022, at 7:12 PM, Jeremy Wood <mickleness at gmail.com> wrote:
> 
> On Macs the tray can present black or white icons, depending on the color of the desktop underneath the menubar.
> 
> For example:
> 
> <galpmnvf.png>
> 
> <qtqoidmn.png>
> 
> Most icons switch from a black icon to a white icon as needed. A few 3rd party app icons do not switch to a white icon against the black background (for ex: Evernote). And interestingly: Apple?s Airdrop icon (the concentric circles shaped like a sideways pacman) also appears to do the wrong thing too.
> 
> Is there a way in a Java desktop app to set up a tray icon that can toggle between white and black icons as needed?
> 
> Obviously we?d love it if this ?just worked? without further intervention by inverting our icon, but we?d also be happy if a solution involved adding a PropertyChangeListener somewhere to identify the menubar change and we could update the tray icons ourselves.
> 
> For ex:
> If I change the highlight/accent color (in ?System Preferences -> General?), then 8 UIManager Colors change (including ?textHighlight?, ?Button.light?, etc.) as of JDK 18. As far as I can tell: there is no similar model to identify when the menubar changes colors.
> 
> For now we?ve made a work-around by using the Robot class to grab a pixel from the Apple menu icon every few seconds to determine if it?s light or dark.
> 
> Is there an existing way to resolve this we don?t know about?
> 
> Or if not: is anyone reading this with ?author? status interested in helping write this up as an openjdk bug?
> 
> Regards,
>  - Jeremy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/0a77d22d/attachment.htm>

From aivanov at openjdk.org  Wed Aug 10 13:48:44 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 10 Aug 2022 13:48:44 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <sOUOMvWHnERHCIFxDaSR4U_66fGIceUTtv8rnMsPAvo=.305be23c-30e0-4ab8-a1db-93fd0ccdc313@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
 <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
 <sOUOMvWHnERHCIFxDaSR4U_66fGIceUTtv8rnMsPAvo=.305be23c-30e0-4ab8-a1db-93fd0ccdc313@github.com>
Message-ID: <bI8VV83mBcpXY-1jehoT0ws1g4JQpHqkTcdQW878hEY=.1fa7be94-eaa5-47c2-a641-9c99c012b54d@github.com>

On Wed, 10 Aug 2022 04:46:59 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> > > @prsadhuk I have made few changes in formatting the file size, using MessageFormat and NumberFormat to format the file size with 1 decimal place precision. Earlier JFileChooser show file size for "1.0" as "1", now it will show one decimal place precision. Empty files show as "0 KB".
> > 
> > 
> > If JFileChooser always shows a decimal point for nearly all files, should it show 0.0 KB for zero-sized files?
> > I guess it would simplify your code as there'll be no reason to change number format.
> 
> @aivanov-jdk It will simplify the code but I checked in native file system and it shows "0 bytes" for zero-sized files. So to keep it similar to native, zero-sized files shown as "0 KB".

Yet still it's shows 0 KB in Java; all other sizes are showed with one digit after the decimal point, thus only 0 KB has special handling. It's different from the native system, and I am for consistency in Java approach. If we decided, we show the size as #.# where there's always a digit after the decimal point, I'd rather see it always displayed. It would be easier to scan the sizes.

I wonder how the file size of 200 bytes is shown: 1 KB or 0.2 KB.

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

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


From duke at openjdk.org  Wed Aug 10 14:23:45 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Aug 2022 14:23:45 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <bI8VV83mBcpXY-1jehoT0ws1g4JQpHqkTcdQW878hEY=.1fa7be94-eaa5-47c2-a641-9c99c012b54d@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
 <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
 <sOUOMvWHnERHCIFxDaSR4U_66fGIceUTtv8rnMsPAvo=.305be23c-30e0-4ab8-a1db-93fd0ccdc313@github.com>
 <bI8VV83mBcpXY-1jehoT0ws1g4JQpHqkTcdQW878hEY=.1fa7be94-eaa5-47c2-a641-9c99c012b54d@github.com>
Message-ID: <EEXnt1A5LDU2Tisrg8_R2yd6HjgNIstbt9_BkIFLuSk=.889a6f03-035d-4648-a8c3-aa43cf6a9d70@github.com>

On Wed, 10 Aug 2022 13:45:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > > @prsadhuk I have made few changes in formatting the file size, using MessageFormat and NumberFormat to format the file size with 1 decimal place precision. Earlier JFileChooser show file size for "1.0" as "1", now it will show one decimal place precision. Empty files show as "0 KB".
> > > 
> > > 
> > > If JFileChooser always shows a decimal point for nearly all files, should it show 0.0 KB for zero-sized files?
> > > I guess it would simplify your code as there'll be no reason to change number format.
> > 
> > 
> > @aivanov-jdk It will simplify the code but I checked in native file system and it shows "0 bytes" for zero-sized files. So to keep it similar to native, zero-sized files shown as "0 KB".
> 
> Yet still it's shows 0 KB in Java; all other sizes are showed with one digit after the decimal point, thus only 0 KB has special handling. It's different from the native system, and I am for consistency in Java approach. If we decided, we show the size as #.# where there's always a digit after the decimal point, I'd rather see it always displayed. It would be easier to scan the sizes.
> 
> I wonder how the file size of 200 bytes is shown: 1 KB or 0.2 KB.

As of now files having size >0 and <1000 bytes are shown as 1.0 KB.

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

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


From mickleness at gmail.com  Wed Aug 10 14:28:25 2022
From: mickleness at gmail.com (Jeremy Wood)
Date: Wed, 10 Aug 2022 14:28:25 +0000
Subject: Mac Tray Icon Question
In-Reply-To: <A481B3B7-1AEC-4B5C-AEF9-92C41F5E8A63@cbfiddle.com>
References: <em32971c20-730c-4b57-b1cd-5a35ee11227d@573fd4be.com>
 <A481B3B7-1AEC-4B5C-AEF9-92C41F5E8A63@cbfiddle.com>
Message-ID: <em81a972b3-aab0-411d-b8a1-c341ecf4be0b@573fd4be.com>

I like that theory, thanks. Is it possible to make/assign a template 
image in Java?

Glancing around just now didn?t turn up any leads. Specifically:

In CTrayIcon#updateNativeImage(Image), we call:
CImage.getCreator().createFromImage(image, observer)

? and that method appears to convert ?image? (a java.awt.Image) into a 
TYPE_INT_ARGB_PRE formatted int array. The word ?template? isn?t in the 
CImage class at all. So even if I had the imagePtr I don?t see how I can 
toggle the template attribute.

Regards,
  - Jeremy

------ Original Message ------
>From "Alan Snyder" <javalists at cbfiddle.com>
To "Jeremy Wood" <mickleness at gmail.com>
Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
Date 8/10/2022 8:25:11 AM
Subject Re: Mac Tray Icon Question

>I suspect the images that work are template images, rather than pairs 
>of images.
>
>See 
>https://developer.apple.com/documentation/appkit/nsimage/1520017-template
>
>
>
>>On Aug 9, 2022, at 7:12 PM, Jeremy Wood <mickleness at gmail.com> wrote:
>>
>>On Macs the tray can present black or white icons, depending on the 
>>color of the desktop underneath the menubar.
>>
>>For example:
>>
>><galpmnvf.png>
>>
>><qtqoidmn.png>
>>
>>Most icons switch from a black icon to a white icon as needed. A few 
>>3rd party app icons do not switch to a white icon against the black 
>>background (for ex: Evernote). And interestingly: Apple?s Airdrop icon 
>>(the concentric circles shaped like a sideways pacman) also appears to 
>>do the wrong thing too.
>>
>>Is there a way in a Java desktop app to set up a tray icon that can 
>>toggle between white and black icons as needed?
>>
>>Obviously we?d love it if this ?just worked? without further 
>>intervention by inverting our icon, but we?d also be happy if a 
>>solution involved adding a PropertyChangeListener somewhere to 
>>identify the menubar change and we could update the tray icons 
>>ourselves.
>>
>>For ex:
>>If I change the highlight/accent color (in ?System Preferences -> 
>>General?), then 8 UIManager Colors change (including ?textHighlight?, 
>>?Button.light?, etc.) as of JDK 18. As far as I can tell: there is no 
>>similar model to identify when the menubar changes colors.
>>
>>For now we?ve made a work-around by using the Robot class to grab a 
>>pixel from the Apple menu icon every few seconds to determine if it?s 
>>light or dark.
>>
>>Is there an existing way to resolve this we don?t know about?
>>
>>Or if not: is anyone reading this with ?author? status interested in 
>>helping write this up as an openjdk bug?
>>
>>Regards,
>>  - Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/41db5d26/attachment.htm>

From aivanov at openjdk.org  Wed Aug 10 14:40:59 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 10 Aug 2022 14:40:59 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <EEXnt1A5LDU2Tisrg8_R2yd6HjgNIstbt9_BkIFLuSk=.889a6f03-035d-4648-a8c3-aa43cf6a9d70@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
 <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
 <sOUOMvWHnERHCIFxDaSR4U_66fGIceUTtv8rnMsPAvo=.305be23c-30e0-4ab8-a1db-93fd0ccdc313@github.com>
 <bI8VV83mBcpXY-1jehoT0ws1g4JQpHqkTcdQW878hEY=.1fa7be94-eaa5-47c2-a641-9c99c012b54d@github.com>
 <EEXnt1A5LDU2Tisrg8_R2yd6HjgNIstbt9_BkIFLuSk=.889a6f03-035d-4648-a8c3-aa43cf6a9d70@github.com>
Message-ID: <_E3H9iGdVTOCSjS15WoL6VAwZUbPX7LLA4xdUUXZ9NE=.a995ba0f-be38-4f65-9b03-e3138a21323b@github.com>

On Wed, 10 Aug 2022 14:19:45 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> > I wonder how the file size of 200 bytes is shown: 1 KB or 0.2 KB.
> 
> As of now files having size >0 and <1000 bytes are shown as 1.0 KB.

And this seems wrong and inconsistent, doesn't it?

If we display the file size with _one decimal point precision_, then it doesn't hold at all until the file size reaches 1 KB.

Whatever the decision we make, I'd like to have a test for 1 KB file and for 0.5 KB file to document how it works. It's the point of having different file sizes in the test, right?

I agree the file sizes less than 1 KB are somewhat uncommon, I'm okay with displaying them as 1.0 KB.

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

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


From javalists at cbfiddle.com  Wed Aug 10 14:47:41 2022
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 10 Aug 2022 07:47:41 -0700
Subject: Mac Tray Icon Question
In-Reply-To: <em81a972b3-aab0-411d-b8a1-c341ecf4be0b@573fd4be.com>
References: <em32971c20-730c-4b57-b1cd-5a35ee11227d@573fd4be.com>
 <A481B3B7-1AEC-4B5C-AEF9-92C41F5E8A63@cbfiddle.com>
 <em81a972b3-aab0-411d-b8a1-c341ecf4be0b@573fd4be.com>
Message-ID: <1CD04BA4-65A6-49D4-9482-9C7A350E4D48@cbfiddle.com>

It appears that CTrayIcon has an option to use template images.

apple.awt.enableTemplateImages

So, either this option is off or your image does not satisfy the rules for template images.




> On Aug 10, 2022, at 7:28 AM, Jeremy Wood <mickleness at gmail.com> wrote:
> 
> I like that theory, thanks. Is it possible to make/assign a template image in Java?
> 
> Glancing around just now didn?t turn up any leads. Specifically:
> 
> In CTrayIcon#updateNativeImage(Image), we call:
> CImage.getCreator().createFromImage(image, observer)
> 
> ? and that method appears to convert ?image? (a java.awt.Image) into a TYPE_INT_ARGB_PRE formatted int array. The word ?template? isn?t in the CImage class at all. So even if I had the imagePtr I don?t see how I can toggle the template attribute.
> 
> Regards,
>  - Jeremy
> 
> ------ Original Message ------
> From "Alan Snyder" <javalists at cbfiddle.com <mailto:javalists at cbfiddle.com>>
> To "Jeremy Wood" <mickleness at gmail.com <mailto:mickleness at gmail.com>>
> Cc "client-libs-dev at openjdk.org <mailto:client-libs-dev at openjdk.org>" <client-libs-dev at openjdk.org <mailto:client-libs-dev at openjdk.org>>
> Date 8/10/2022 8:25:11 AM
> Subject Re: Mac Tray Icon Question
> 
>> I suspect the images that work are template images, rather than pairs of images.
>> 
>> See https://developer.apple.com/documentation/appkit/nsimage/1520017-template <https://developer.apple.com/documentation/appkit/nsimage/1520017-template>
>> 
>> 
>> 
>>> On Aug 9, 2022, at 7:12 PM, Jeremy Wood <mickleness at gmail.com <mailto:mickleness at gmail.com>> wrote:
>>> 
>>> On Macs the tray can present black or white icons, depending on the color of the desktop underneath the menubar.
>>> 
>>> For example:
>>> 
>>> <galpmnvf.png>
>>> 
>>> <qtqoidmn.png>
>>> 
>>> Most icons switch from a black icon to a white icon as needed. A few 3rd party app icons do not switch to a white icon against the black background (for ex: Evernote). And interestingly: Apple?s Airdrop icon (the concentric circles shaped like a sideways pacman) also appears to do the wrong thing too.
>>> 
>>> Is there a way in a Java desktop app to set up a tray icon that can toggle between white and black icons as needed?
>>> 
>>> Obviously we?d love it if this ?just worked? without further intervention by inverting our icon, but we?d also be happy if a solution involved adding a PropertyChangeListener somewhere to identify the menubar change and we could update the tray icons ourselves.
>>> 
>>> For ex:
>>> If I change the highlight/accent color (in ?System Preferences -> General?), then 8 UIManager Colors change (including ?textHighlight?, ?Button.light?, etc.) as of JDK 18. As far as I can tell: there is no similar model to identify when the menubar changes colors.
>>> 
>>> For now we?ve made a work-around by using the Robot class to grab a pixel from the Apple menu icon every few seconds to determine if it?s light or dark.
>>> 
>>> Is there an existing way to resolve this we don?t know about?
>>> 
>>> Or if not: is anyone reading this with ?author? status interested in helping write this up as an openjdk bug?
>>> 
>>> Regards,
>>>  - Jeremy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/fc2493b3/attachment.htm>

From philip.race at oracle.com  Wed Aug 10 15:41:53 2022
From: philip.race at oracle.com (Philip Race)
Date: Wed, 10 Aug 2022 08:41:53 -0700
Subject: Mac Tray Icon Question
In-Reply-To: <1CD04BA4-65A6-49D4-9482-9C7A350E4D48@cbfiddle.com>
References: <em32971c20-730c-4b57-b1cd-5a35ee11227d@573fd4be.com>
 <A481B3B7-1AEC-4B5C-AEF9-92C41F5E8A63@cbfiddle.com>
 <em81a972b3-aab0-411d-b8a1-c341ecf4be0b@573fd4be.com>
 <1CD04BA4-65A6-49D4-9482-9C7A350E4D48@cbfiddle.com>
Message-ID: <3b9bab9c-d50c-7883-77ac-e7d415b6874c@oracle.com>


This was implemented in JDK 17 as 
https://bugs.openjdk.org/browse/JDK-8252015
You need to set that property yourself and then ALL your images for 
TrayIcon had better
all be template images else it will likely look very bad ..

It was done this way to avoid "accidentally" interpretation of images as 
template images
Personally I wonder if the definition of template images is simple and 
stable we could
just scan the images to see if they meet the criteria and then mark them 
as template
images automatically .. but very clearly the developer would need to 
know the rules
for template images and supply these for mac. There's nothing I can 
think of which
would allow someone writing a Java app on Windows and not a mac aware 
developer
to have this magically done for them ...

-phil.

On 8/10/22 7:47 AM, Alan Snyder wrote:
> It appears that CTrayIcon has an option to use template images.
>
> apple.awt.enableTemplateImages
>
> So, either this option is off or your image does not satisfy the rules 
> for template images.
>
>
>
>
>> On Aug 10, 2022, at 7:28 AM, Jeremy Wood <mickleness at gmail.com> wrote:
>>
>> I like that theory, thanks.?Is it possible to make/assign a template 
>> image in Java?
>>
>> Glancing around just now didn?t turn up any leads. Specifically:
>>
>> In CTrayIcon#updateNativeImage(Image), we call:
>> CImage.getCreator().createFromImage(image, observer)
>>
>> ? and that method appears to convert ?image? (a java.awt.Image) into 
>> a TYPE_INT_ARGB_PRE formatted int array. The word ?template? isn?t in 
>> the CImage class at all. So even if I had the imagePtr I don?t see 
>> how I can toggle the template attribute.
>>
>> Regards,
>> ?- Jeremy
>>
>> ------ Original Message ------
>> From "Alan Snyder" <javalists at cbfiddle.com>
>> To "Jeremy Wood" <mickleness at gmail.com>
>> Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
>> Date 8/10/2022 8:25:11 AM
>> Subject Re: Mac Tray Icon Question
>>
>>> I suspect the images that work are template images, rather than 
>>> pairs of images.
>>>
>>> See 
>>> https://developer.apple.com/documentation/appkit/nsimage/1520017-template
>>>
>>>
>>>
>>>> On Aug 9, 2022, at 7:12 PM, Jeremy Wood <mickleness at gmail.com> wrote:
>>>>
>>>> On Macs the tray can present black or white icons, depending on the 
>>>> color of the desktop underneath the menubar.
>>>>
>>>> For example:
>>>>
>>>> <galpmnvf.png>
>>>>
>>>> <qtqoidmn.png>
>>>>
>>>> Most icons switch from a black icon to a white icon as needed. A 
>>>> few 3rd party app icons do not switch to a white icon against the 
>>>> black background (for ex: Evernote). And interestingly: Apple?s 
>>>> Airdrop icon (the concentric circles shaped like a sideways pacman) 
>>>> also appears to do the wrong thing too.
>>>>
>>>> Is there a way in a Java desktop app to set up a tray icon that can 
>>>> toggle between white and black icons as needed?
>>>>
>>>> Obviously we?d love it if this ?just worked? without further 
>>>> intervention by inverting our icon, but we?d also be happy if a 
>>>> solution involved adding a PropertyChangeListener somewhere to 
>>>> identify the menubar change and we could update the tray icons 
>>>> ourselves.
>>>>
>>>> For ex:
>>>> If I change the highlight/accent color (in ?System Preferences -> 
>>>> General?), then 8 UIManager Colors change (including 
>>>> ?textHighlight?, ?Button.light?, etc.) as of JDK 18. As far as I 
>>>> can tell: there is no similar model to identify when the menubar 
>>>> changes colors.
>>>>
>>>> For now we?ve made a work-around by using the Robot class to grab a 
>>>> pixel from the Apple menu icon every few seconds to determine if 
>>>> it?s light or dark.
>>>>
>>>> Is there an existing way to resolve this we don?t know about?
>>>>
>>>> Or if not: is anyone reading this with ?author? status interested 
>>>> in helping write this up as an openjdk bug?
>>>>
>>>> Regards,
>>>> ?- Jeremy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/125b9757/attachment.htm>

From duke at openjdk.org  Wed Aug 10 15:48:42 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Aug 2022 15:48:42 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v15]
In-Reply-To: <_E3H9iGdVTOCSjS15WoL6VAwZUbPX7LLA4xdUUXZ9NE=.a995ba0f-be38-4f65-9b03-e3138a21323b@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <1LurmijmkSJmjfr-XHy1h2EFjOXXvAOIFaY1V9NjcsI=.feb514a7-2982-4df5-98a2-f3d242badce8@github.com>
 <bYoUltyynspr-WrqVgLyodBUt_kIYVj37lHKgqqROYw=.4f825243-0883-4332-9d2c-fd5aa57fd63a@github.com>
 <fMOkGrWLCXuIQBX2iO8896z8sV7VPJTNAraem47XHHc=.10737e12-694f-4862-aff2-7a19f5d7a986@github.com>
 <sOUOMvWHnERHCIFxDaSR4U_66fGIceUTtv8rnMsPAvo=.305be23c-30e0-4ab8-a1db-93fd0ccdc313@github.com>
 <bI8VV83mBcpXY-1jehoT0ws1g4JQpHqkTcdQW878hEY=.1fa7be94-eaa5-47c2-a641-9c99c012b54d@github.com>
 <EEXnt1A5LDU2Tisrg8_R2yd6HjgNIstbt9_BkIFLuSk=.889a6f03-035d-4648-a8c3-aa43cf6a9d70@github.com>
 <_E3H9iGdVTOCSjS15WoL6VAwZUbPX7LLA4xdUUXZ9NE=.a995ba0f-be38-4f65-9b03-e3138a21323b@github.com>
Message-ID: <iQBlZhfKEJlqA_2nlbZXJFPpQO0nm5n-Od0OKaiH5Nw=.90a09ee7-b035-4701-ad7e-9bbcfc721a00@github.com>

On Wed, 10 Aug 2022 14:38:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > I wonder how the file size of 200 bytes is shown: 1 KB or 0.2 KB.
> > 
> > 
> > As of now files having size >0 and <1000 bytes are shown as 1.0 KB.
> 
> And this seems wrong and inconsistent, doesn't it?
> 
> If we display the file size with _one decimal point precision_, then it doesn't hold at all until the file size reaches 1 KB.
> 
> Whatever the decision we make, I'd like to have a test for 1 KB file and for 0.5 KB file to document how it works. It's the point of having different file sizes in the test, right?
> 
> I agree the file sizes less than 1 KB are somewhat uncommon, I'm okay with displaying them as 1.0 KB.

Yeah, you are right if we display the file size with _one decimal point precision_ then it is inconsistent. 
I will add the test files for 1 KB and 0.5 KB.

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

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


From chen.j.patrick at gmail.com  Tue Aug  2 11:34:38 2022
From: chen.j.patrick at gmail.com (Patrick Chen)
Date: Tue, 2 Aug 2022 13:34:38 +0200
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S
 in a button.
In-Reply-To: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
Message-ID: <CANmuJ8tMYXRSvyK3OHhbCwnuS83TAntBML=2Dhwvj_8f7zN01g@mail.gmail.com>

is it the only case  ?
is there other keycode with the same issue?

Le mar. 2 ao?t 2022 ? 12:47, Prasanta Sadhukhan <psadhukhan at openjdk.org> a
?crit :

> It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the
> letter 'S' in the JButton to be underlined if JButton's text has 'S' in its
> string.
> This is because [**VK_F4**](
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506)
> keycode is 0x73 (115 in decimal) which happens to be value of lowercase
> [**'s'** ](
> https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as
> per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(),
> the first index of the character (either lowecasr or uppercase) is returned
> as a mnemonic, which gets underlined.
>
> Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic
> which corresponds to lowercase p->z
>
> -------------
>
> Commit messages:
>  - Fix
>  - Fix
>  - 4850101: Setting mnemonic to VK_F4 underlines the letter S in a button.
>
> Changes: https://git.openjdk.org/jdk/pull/9712/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9712&range=00
>   Issue: https://bugs.openjdk.org/browse/JDK-4850101
>   Stats: 139 lines in 2 files changed: 139 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.org/jdk/pull/9712.diff
>   Fetch: git fetch https://git.openjdk.org/jdk pull/9712/head:pull/9712
>
> PR: https://git.openjdk.org/jdk/pull/9712
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220802/cb2b6570/attachment.htm>

From mickleness at gmail.com  Wed Aug 10 15:50:07 2022
From: mickleness at gmail.com (Jeremy Wood)
Date: Wed, 10 Aug 2022 15:50:07 +0000
Subject: Mac Tray Icon Question
In-Reply-To: <3b9bab9c-d50c-7883-77ac-e7d415b6874c@oracle.com>
References: <em32971c20-730c-4b57-b1cd-5a35ee11227d@573fd4be.com>
 <A481B3B7-1AEC-4B5C-AEF9-92C41F5E8A63@cbfiddle.com>
 <em81a972b3-aab0-411d-b8a1-c341ecf4be0b@573fd4be.com>
 <1CD04BA4-65A6-49D4-9482-9C7A350E4D48@cbfiddle.com>
 <3b9bab9c-d50c-7883-77ac-e7d415b6874c@oracle.com>
Message-ID: <em2ff13c81-8537-41b2-8aab-68774b29db41@573fd4be.com>

Alan & Phil:

Thanks so much. I just ran a test in JDK 18 with 
?apple.awt.enableTemplateImages? set to true and it works as expected. 
(I realize now part of the problem was on one of my machines I was 
reading JDK 14 code, but I?m not 100% sure even if I had the correct 
version in front of me that I would have pieced all of this together...)

  Regards,
  - Jeremy

------ Original Message ------
>From "Philip Race" <philip.race at oracle.com>
To "alan Snyder" <fishgarage at cbfiddle.com>; "Jeremy Wood" 
<mickleness at gmail.com>
Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
Date 8/10/2022 11:41:53 AM
Subject Re: Mac Tray Icon Question

>
>This was implemented in JDK 17 as 
>https://bugs.openjdk.org/browse/JDK-8252015
>You need to set that property yourself and then ALL your images for 
>TrayIcon had better
>all be template images else it will likely look very bad ..
>
>It was done this way to avoid "accidentally" interpretation of images 
>as template images
>Personally I wonder if the definition of template images is simple and 
>stable we could
>just scan the images to see if they meet the criteria and then mark 
>them as template
>images automatically .. but very clearly the developer would need to 
>know the rules
>for template images and supply these for mac. There's nothing I can 
>think of which
>would allow someone writing a Java app on Windows and not a mac aware 
>developer
>to have this magically done for them ...
>
>-phil.
>
>On 8/10/22 7:47 AM, Alan Snyder wrote:
>>It appears that CTrayIcon has an option to use template images.
>>
>>apple.awt.enableTemplateImages
>>
>>So, either this option is off or your image does not satisfy the rules 
>>for template images.
>>
>>
>>
>>
>>>On Aug 10, 2022, at 7:28 AM, Jeremy Wood <mickleness at gmail.com> 
>>>wrote:
>>>
>>>I like that theory, thanks. Is it possible to make/assign a template 
>>>image in Java?
>>>
>>>Glancing around just now didn?t turn up any leads. Specifically:
>>>
>>>In CTrayIcon#updateNativeImage(Image), we call:
>>>CImage.getCreator().createFromImage(image, observer)
>>>
>>>? and that method appears to convert ?image? (a java.awt.Image) into 
>>>a TYPE_INT_ARGB_PRE formatted int array. The word ?template? isn?t in 
>>>the CImage class at all. So even if I had the imagePtr I don?t see 
>>>how I can toggle the template attribute.
>>>
>>>Regards,
>>>  - Jeremy
>>>
>>>------ Original Message ------
>>>From "Alan Snyder" <javalists at cbfiddle.com>
>>>To "Jeremy Wood" <mickleness at gmail.com>
>>>Cc "client-libs-dev at openjdk.org" <client-libs-dev at openjdk.org>
>>>Date 8/10/2022 8:25:11 AM
>>>Subject Re: Mac Tray Icon Question
>>>
>>>>I suspect the images that work are template images, rather than 
>>>>pairs of images.
>>>>
>>>>See 
>>>>https://developer.apple.com/documentation/appkit/nsimage/1520017-template
>>>>
>>>>
>>>>
>>>>>On Aug 9, 2022, at 7:12 PM, Jeremy Wood <mickleness at gmail.com> 
>>>>>wrote:
>>>>>
>>>>>On Macs the tray can present black or white icons, depending on the 
>>>>>color of the desktop underneath the menubar.
>>>>>
>>>>>For example:
>>>>>
>>>>><galpmnvf.png>
>>>>>
>>>>><qtqoidmn.png>
>>>>>
>>>>>Most icons switch from a black icon to a white icon as needed. A 
>>>>>few 3rd party app icons do not switch to a white icon against the 
>>>>>black background (for ex: Evernote). And interestingly: Apple?s 
>>>>>Airdrop icon (the concentric circles shaped like a sideways pacman) 
>>>>>also appears to do the wrong thing too.
>>>>>
>>>>>Is there a way in a Java desktop app to set up a tray icon that can 
>>>>>toggle between white and black icons as needed?
>>>>>
>>>>>Obviously we?d love it if this ?just worked? without further 
>>>>>intervention by inverting our icon, but we?d also be happy if a 
>>>>>solution involved adding a PropertyChangeListener somewhere to 
>>>>>identify the menubar change and we could update the tray icons 
>>>>>ourselves.
>>>>>
>>>>>For ex:
>>>>>If I change the highlight/accent color (in ?System Preferences -> 
>>>>>General?), then 8 UIManager Colors change (including 
>>>>>?textHighlight?, ?Button.light?, etc.) as of JDK 18. As far as I 
>>>>>can tell: there is no similar model to identify when the menubar 
>>>>>changes colors.
>>>>>
>>>>>For now we?ve made a work-around by using the Robot class to grab a 
>>>>>pixel from the Apple menu icon every few seconds to determine if 
>>>>>it?s light or dark.
>>>>>
>>>>>Is there an existing way to resolve this we don?t know about?
>>>>>
>>>>>Or if not: is anyone reading this with ?author? status interested 
>>>>>in helping write this up as an openjdk bug?
>>>>>
>>>>>Regards,
>>>>>  - Jeremy
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/d854d354/attachment.htm>

From alexey.ushakov at jetbrains.com  Wed Aug 10 16:36:50 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Wed, 10 Aug 2022 18:36:50 +0200
Subject: Question re -Dsun.java2d.cmm possible available options
In-Reply-To: <CAP-W_Nu1jP-M-W+fKs15xi0p0EZzHif=OiVqtXsK1j-iMSUWng@mail.gmail.com>
References: <CAP-W_Nu1jP-M-W+fKs15xi0p0EZzHif=OiVqtXsK1j-iMSUWng@mail.gmail.com>
Message-ID: <F662BD8B-1B66-4651-92F2-1D422A263F71@jetbrains.com>

Hello Alex,

This option (-Dsun.java2d.cmm ) was implemented to switch between proprietary Color Management library from Kodak and open source Little CMS during transition JDK to open source (See https://bugs.openjdk.org/browse/JDK-6476534 <https://bugs.openjdk.org/browse/JDK-6476534> for more info). Another candidate was Sample ICC (https://www.color.org/sampleicc.xalter) but it is C++ not java.

Best Regards,
Alexey 

> On 6 Jul 2022, at 23:24, Alex Andryushkin <alex.andryushkin at corista.com> wrote:
> 
> Hello,
> 
> I am sorry for the wide distribution or if I am reaching out to the wrong group.
> 
> I am running into issues with using awt/java2d color conversion between ICC profiles.
> It seems to be boiling down to the native library (little-csm) used in java2d.cmm.lcms by default.
> At the same time I think there is an option -Dsun.java2d.cmm defaulting to sun.java2d.cmm.lcms.LcmsServiceProvider, hence it feels that there could be other providers, hopefully not dependent on little-csm. But I was not able to find any.
> 
> Question: Are there known alternatives to sun.java2d.cmm.lcms.LcmsServiceProvider, which can be used as an override, with -Dsun.java2d.cmm option. Preferably a pure-java implementation, even though it will be slower.
> 
> Thank you,
> ~ Alex.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/252a50bf/attachment.htm>

From philip.race at oracle.com  Wed Aug 10 16:45:33 2022
From: philip.race at oracle.com (Philip Race)
Date: Wed, 10 Aug 2022 09:45:33 -0700
Subject: Question re -Dsun.java2d.cmm possible available options
In-Reply-To: <F662BD8B-1B66-4651-92F2-1D422A263F71@jetbrains.com>
References: <CAP-W_Nu1jP-M-W+fKs15xi0p0EZzHif=OiVqtXsK1j-iMSUWng@mail.gmail.com>
 <F662BD8B-1B66-4651-92F2-1D422A263F71@jetbrains.com>
Message-ID: <e5b333b0-c563-2335-3b72-a6edd8454d3f@oracle.com>

Right. And it was never intended to allow an app to provide the CMM .. 
it was just
for choosing between built-in ones.

We probably can ditch the code that reads the property now since it 
hasn't had any purpose since (IIRC) JDK 9.

Perhaps - if you believe it is really a LCMS issue, that you start by 
reporting your problem to
the upstream littlecms project.

But if it is a JDK-specific issue in the way we use LCMS or the profiles 
bundled with OpenJDK
then you should file a JDK bug report at 
https://bugreport.java.com/bugreport/

-phil.

On 8/10/22 9:36 AM, Alexey Ushakov wrote:
> Hello Alex,
>
> This option (-Dsun.java2d.cmm ) was implemented to switch between 
> proprietary Color Management library from Kodak and open source Little 
> CMS during transition JDK to open source (See 
> https://bugs.openjdk.org/browse/JDK-6476534?for more info). Another 
> candidate was?Sample ICC (https://www.color.org/sampleicc.xalter) but 
> it is C++ not java.
>
> Best Regards,
> Alexey
>
>> On 6 Jul 2022, at 23:24, Alex Andryushkin 
>> <alex.andryushkin at corista.com> wrote:
>>
>> Hello,
>>
>> I am sorry for the wide distribution or if I am reaching out to the 
>> wrong group.
>>
>> I am running into issues with using awt/java2d color conversion 
>> between ICC profiles.
>> It seems to be boiling down to the native library (little-csm) used 
>> in java2d.cmm.lcms by default.
>> At the same time I think there is an option -Dsun.java2d.cmm 
>> defaulting to sun.java2d.cmm.lcms.LcmsServiceProvider, hence it feels 
>> that there could be other providers, hopefully not dependent on 
>> little-csm. But I was not able to find any.
>>
>> Question: Are there known alternatives to 
>> sun.java2d.cmm.lcms.LcmsServiceProvider, which can be used as an 
>> override, with -Dsun.java2d.cmm option. Preferably?a pure-java 
>> implementation, even though it will be slower.
>>
>> Thank you,
>> ~ Alex.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20220810/954c59d4/attachment.htm>

From prr at openjdk.org  Wed Aug 10 17:52:45 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Aug 2022 17:52:45 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
Message-ID: <ybJzApQsTKCxFtGWIHNoCqdOm9F148KiBEAhG4IVis8=.25c24784-6d66-45eb-9d62-226277d81620@github.com>

On Wed, 10 Aug 2022 05:30:56 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated as per  review comments

>> If we display the file size with one decimal point precision, then it doesn't hold at all until the file size reaches 1 KB.

Is your point ( pun intended) that it looks like we are displaying files to a decimal precision, but in fact are not ?

ie it is very odd to display 1.0kb for files of 100, 200, 300, etc bytes .. 
What is the reason for displaying them all as 1.0kb .. this review is so long I'm not sure I am following any more.

Could we get a summary in a few sentences of the entire current proposal and the justification for it ?

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

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


From duke at openjdk.org  Wed Aug 10 18:25:49 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Aug 2022 18:25:49 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <ybJzApQsTKCxFtGWIHNoCqdOm9F148KiBEAhG4IVis8=.25c24784-6d66-45eb-9d62-226277d81620@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
 <ybJzApQsTKCxFtGWIHNoCqdOm9F148KiBEAhG4IVis8=.25c24784-6d66-45eb-9d62-226277d81620@github.com>
Message-ID: <HzVciOi9SjPDdYnoLy8T7LNsKsmtje3IWniUcwDXU_E=.b981ed88-841f-4b16-8d95-aa6237edc4ae@github.com>

On Wed, 10 Aug 2022 17:49:14 GMT, Phil Race <prr at openjdk.org> wrote:

> > > If we display the file size with one decimal point precision, then it doesn't hold at all until the file size reaches 1 KB.
> 
> Is your point ( pun intended) that it looks like we are displaying files to a decimal precision, but in fact are not ?
> 
> ie it is very odd to display 1.0kb for files of 100, 200, 300, etc bytes .. What is the reason for displaying them all as 1.0kb .. this review is so long I'm not sure I am following any more.
> 
> Could we get a summary in a few sentences of the entire current proposal and the justification for it ?

There was an issue with plural forms if we show file sizes in terms of bytes. So, it has been discussed that 
we can show the file size in terms of "1 KB" for files having size >0 and <1000 bytes. To keep file size similar to native file system, JFileChooser displays file sizes with one decimal point precision.

Now, the issue is whether an empty file should be displayed as "0.0 KB" or "0 KB" ? 
As of now empty files are displayed as "0 KB".

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

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


From aivanov at openjdk.org  Wed Aug 10 18:42:01 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 10 Aug 2022 18:42:01 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <HzVciOi9SjPDdYnoLy8T7LNsKsmtje3IWniUcwDXU_E=.b981ed88-841f-4b16-8d95-aa6237edc4ae@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
 <ybJzApQsTKCxFtGWIHNoCqdOm9F148KiBEAhG4IVis8=.25c24784-6d66-45eb-9d62-226277d81620@github.com>
 <HzVciOi9SjPDdYnoLy8T7LNsKsmtje3IWniUcwDXU_E=.b981ed88-841f-4b16-8d95-aa6237edc4ae@github.com>
Message-ID: <VUaQI-2OcXc_VryjznoG2M_7WrzzuP-9u0XVMJJux-c=.cd4822f9-afda-41d6-99d9-8289ce4f700e@github.com>

On Wed, 10 Aug 2022 18:22:04 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> > > > If we display the file size with one decimal point precision, then it doesn't hold at all until the file size reaches 1 KB.
> > 
> > Is your point ( pun intended) that it looks like we are displaying files to a decimal precision, but in fact are not ?

That's exactly my point.


> > Could we get a summary in a few sentences of the entire current proposal and the justification for it ?

I also asked for the summary. That time it was a bit different:
https://github.com/openjdk/jdk/pull/9327#discussion_r939828467

> There was an issue with plural forms if we show file sizes in terms of bytes. So, it has been discussed that we can show the file size in terms of "1 KB" for files having size >0 and <1000 bytes. To keep file size similar to native file system, JFileChooser displays file sizes with one decimal point precision.
> 
> Now, the issue is whether an empty file should be displayed as "0.0 KB" or "0 KB" ? As of now empty files are displayed as "0 KB".

The original issue is that we displayed a zero-sized file as 1 KB. It's stated in the bug subject and in the bug description with more details.

The initial fix was to display it as 0 bytes, which leads to localisation problems, especially if we take into account 1 byte.

Eventually, it was decided to display the size in KB. Thus zero-sized file is displayed as 0 KB, and one-byte-sized file is displayed as 1 KB. This is fine.

Later on, the decimal point was added to mimic native file navigation app in Ubuntu. Now for files larger than 1 KB, the size is shown up to one decimal point. Yet all the files below 1 KB are still displayed as 1 KB. I think it is confusing. If we care to display the size with one decimal point for larger files, why can't we display the size of smaller files with the same precision?

So, 0 bytes is 0.0 KB; > 0 and <= 100 bytes is 0.1 KB, and so on.

Alternatively, drop the decimal altogether.

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

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


From prr at openjdk.org  Wed Aug 10 19:32:46 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 10 Aug 2022 19:32:46 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
Message-ID: <Mob16bWMjoymF5RoSMaTCfGWk6qc4gdKCzNX6U1enr0=.a33baf4e-b0ad-44ac-95fa-b283026f7850@github.com>

On Wed, 10 Aug 2022 05:30:56 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated as per  review comments

To have all files 1->1000 bytes be 1.0kB and  yet 1,100 -> 1,200 bytes be 1.1kB does seem anomalous
from a precision perspective, since the major order of magnitude would seem to be more important to describe.

Since we already aren't going to say "bytes" for those small files, then just getting that precision with
 the decimal point seems better - as well as being consistent !

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

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


From aturbanov at openjdk.org  Thu Aug 11 06:26:06 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 11 Aug 2022 06:26:06 GMT
Subject: Integrated: 8292026: Remove redundant allocations from
 DoubleByteEncoder
In-Reply-To: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
References: <mkxZ89CHSZ-K7iNOQ2JMqge6hFVIdLOlp1qck9kQGlY=.84ec6d92-9458-4acd-a176-6c77cb3435ed@github.com>
Message-ID: <UlT7i-Q93PGy5VEiEXUC6L0ViDMjlin7UNatIp-GfY0=.2e26408a-7c01-4d72-9fff-1c6e499bab01@github.com>

On Fri, 5 Aug 2022 07:07:57 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> There are couple places where new byte array is allocated and then thrown away.

This pull request has now been integrated.

Changeset: 2ddf7287
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ddf72874faedaca6f526bdabd53521c825cf1d0
Stats:     11 lines in 1 file changed: 0 ins; 5 del; 6 mod

8292026: Remove redundant allocations from DoubleByteEncoder

Reviewed-by: prr

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

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


From duke at openjdk.org  Thu Aug 11 10:02:56 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 11 Aug 2022 10:02:56 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

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

  Smaller file sizes display one decimal precision

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/e699f033..1d830a54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=15-16

  Stats: 27 lines in 2 files changed: 8 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

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


From duke at openjdk.org  Thu Aug 11 10:04:21 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 11 Aug 2022 10:04:21 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <Mob16bWMjoymF5RoSMaTCfGWk6qc4gdKCzNX6U1enr0=.a33baf4e-b0ad-44ac-95fa-b283026f7850@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
 <Mob16bWMjoymF5RoSMaTCfGWk6qc4gdKCzNX6U1enr0=.a33baf4e-b0ad-44ac-95fa-b283026f7850@github.com>
Message-ID: <S026tTt1Iuik420kVeeuAAaYilA8NGrU-Gz0FxUUkMA=.1fbfba4a-4f64-4597-83c5-a0fc6b9449fe@github.com>

On Wed, 10 Aug 2022 19:30:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated as per  review comments
>
> To have all files 1->1000 bytes be 1.0kB and  yet 1,100 -> 1,200 bytes be 1.1kB does seem anomalous
> from a precision perspective, since the major order of magnitude would seem to be more important to describe.
> 
> Since we already aren't going to say "bytes" for those small files, then just getting that precision with
>  the decimal point seems better - as well as being consistent !

@prrace @aivanov-jdk I have modified the existing logic to show decimal precision for smaller files.
Added few test cases for files having size <1000 bytes.

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

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


From alanb at openjdk.org  Thu Aug 11 10:54:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Aug 2022 10:54:23 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <VUAwvj9XIcUHj_6p39FQXvmebJhvAh52kbBvcmFFBio=.de2355d0-4d71-4e8e-a53c-aaee8c6865c4@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <SH61rVjJMYU3UUM1oh3xCLk0ev13zOfxr1wx97gvLqU=.fbe65bc3-adac-431c-8389-e3546bbdbc6c@github.com>
 <4_tM2zGhsWXglCYtdZqgGXMHreTRhRYnXVVgo8TvOM8=.91d4ddf2-70c7-43f5-bdc2-77a290c5d70c@github.com>
 <VUAwvj9XIcUHj_6p39FQXvmebJhvAh52kbBvcmFFBio=.de2355d0-4d71-4e8e-a53c-aaee8c6865c4@github.com>
Message-ID: <zrVapX-FELOvfOcTQnt-xJwJh67UjQoSUyR4LF9vXiE=.b82fd2c1-9922-4912-a927-8c5255c4ca92@github.com>

On Wed, 3 Aug 2022 05:59:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> One other comment on this is that the proposed change should mean that the tests no longer need to run with --enable-preview.
>> 
>> You've lost me all over again.
>> Why did these two tests need that in the first place and why would they no longer need it ?
>> 
>> My best guess is that it was added so that the tests deliberately provoked using continuations to verify everything worked but that with the change there's no point since it won't load any classes that use them .. ?
>
>> My best guess is that it was added so that the tests deliberately provoked using continuations to verify everything worked but that with the change there's no point since it won't load any classes that use them .. ?
> 
> That's right. These tests triggered the initialization of classes that depend on the VM being started with --enable-preview. With the proposed change here, the classes will be loaded but not initialized so it won't execute code that needs preview features to be enabled.

> Thanks, @AlanBateman ! Let's wait and see if @prrace approves the change.

I didn't see any more from @prrace. If you don't get a response in the next day or so then I would suggest just integrating this. It will help others that are testing ports that don't have the VM continuation support at this time.

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

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


From djelinski at openjdk.org  Thu Aug 11 12:39:10 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 11 Aug 2022 12:39:10 GMT
Subject: RFR: 8292244: Remove unnecessary include directories
Message-ID: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>

Remove `java.base:include` from `EXTRA_HEADER_DIRS`.

The directory contains base versions of the files present in `<build>/support/modules_include/java.base`; the latter is automatically [included in every JDK library build](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L434).

Verified that:
- cl.exe command line contains `-I<stuff>/modules_include/java.base`
- Windows, Linux and Mac builds still pass

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

Commit messages:
 - Remove one more
 - Simplify includes

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

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


From aoqi at openjdk.org  Thu Aug 11 13:16:27 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 11 Aug 2022 13:16:27 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName
In-Reply-To: <zrVapX-FELOvfOcTQnt-xJwJh67UjQoSUyR4LF9vXiE=.b82fd2c1-9922-4912-a927-8c5255c4ca92@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <SH61rVjJMYU3UUM1oh3xCLk0ev13zOfxr1wx97gvLqU=.fbe65bc3-adac-431c-8389-e3546bbdbc6c@github.com>
 <4_tM2zGhsWXglCYtdZqgGXMHreTRhRYnXVVgo8TvOM8=.91d4ddf2-70c7-43f5-bdc2-77a290c5d70c@github.com>
 <VUAwvj9XIcUHj_6p39FQXvmebJhvAh52kbBvcmFFBio=.de2355d0-4d71-4e8e-a53c-aaee8c6865c4@github.com>
 <zrVapX-FELOvfOcTQnt-xJwJh67UjQoSUyR4LF9vXiE=.b82fd2c1-9922-4912-a927-8c5255c4ca92@github.com>
Message-ID: <t1pxHODPuXLNa5d_QHwweKVeeG3Gp7R-KdLNvy3dGGI=.a9339178-12ad-4860-aded-baaab70f98dc@github.com>

On Thu, 11 Aug 2022 10:52:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Thanks, @AlanBateman ! Let's wait and see if @prrace approves the change.
> 
> I didn't see any more from @prrace. If you don't get a response in the next day or so then I would suggest just integrating this. It will help others that are testing ports that don't have the VM continuation support at this time.

Agree. I will integrate this about two hours later.

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

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


From erikj at openjdk.org  Thu Aug 11 13:17:25 2022
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 11 Aug 2022 13:17:25 GMT
Subject: RFR: 8292244: Remove unnecessary include directories
In-Reply-To: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
References: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
Message-ID: <ySknLd56uwrTkhhxCWYbuTxAxf5D4vahnJI-XFCnrKg=.80fb53ce-3512-4eb1-9b0d-aa91f4458e2e@github.com>

On Thu, 11 Aug 2022 09:56:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove `java.base:include` from `EXTRA_HEADER_DIRS`.
> 
> The directory contains base versions of the files present in `<build>/support/modules_include/java.base`; the latter is automatically [included in every JDK library build](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L434).
> 
> Verified that:
> - cl.exe command line contains `-I<stuff>/modules_include/java.base`
> - Windows, Linux and Mac builds still pass

Marked as reviewed by erikj (Reviewer).

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

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


From duke at openjdk.org  Thu Aug 11 13:49:26 2022
From: duke at openjdk.org (Dio Brando)
Date: Thu, 11 Aug 2022 13:49:26 GMT
Subject: RFR: 8292244: Remove unnecessary include directories
In-Reply-To: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
References: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
Message-ID: <3nbYm0zbO9QPxfU9YcPCLO3rj4Yk6eFr-VHUXzHuNs0=.8220c6e6-925b-47c2-981f-120c8e425506@github.com>

On Thu, 11 Aug 2022 09:56:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove `java.base:include` from `EXTRA_HEADER_DIRS`.
> 
> The directory contains base versions of the files present in `<build>/support/modules_include/java.base`; the latter is automatically [included in every JDK library build](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L434).
> 
> Verified that:
> - cl.exe command line contains `-I<stuff>/modules_include/java.base`
> - Windows, Linux and Mac builds still pass

Marked as reviewed by AJ1032480 at github.com (no known OpenJDK username).

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

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


From dnguyen at openjdk.org  Thu Aug 11 14:09:43 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Aug 2022 14:09:43 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v2]
In-Reply-To: <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <LkQdgEYOHf_gRdVOkDDGjDfXkQeztRJbOiA2gFwvfxo=.febc9fae-db57-45b2-b907-151da03673fa@github.com>
Message-ID: <lYpa4E2XjCcga-pXK0cluTdLIG2PV4cApQFDTor_14k=.63befd72-4a8d-4e76-82a5-7fa8f9c1a8d8@github.com>

On Tue, 12 Jul 2022 22:56:37 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Updated method names for PassFailJFrame
>  - Merge branch 'openjdk:master' into 8054572/JComboBoxBorderAlignmentFix
>  - Removed commented lines. Added newlines.
>  - Updated test with PassFailJFrame
>  - Added test
>  - Adjusted height and coordinate for editable JComboBox

The solution I worked towards was to match the behavior of the non-editable combo box in Aqua L&F. This is because, as previously mentioned, the button's visual size can't change. If the arrow button's size is increased, space will be dedicated for the button in its container and the button will function if clicked within that space but the button would still appear to be the same size (which would be too small for larger text fields). 

So, the text field will not resize in height according to the font and the font would remain the larger font size of 30 in this example. This requires me to override the rectangle calculation method and update the logic for an editable text field of varying font sizes to correctly center the text field to be aligned with the arrow button.

<img width="577" alt="Screen Shot 2022-08-11 at 6 55 47 AM" src="https://user-images.githubusercontent.com/96267980/184151129-8615a505-e8cd-4ffa-9184-52187f713fc5.png">

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

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


From duke at openjdk.org  Thu Aug 11 15:25:27 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 11 Aug 2022 15:25:27 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
Message-ID: <_tYLMq1LG3-2ft_r3k7Rj4cbSgUWOe9_0BesfO1kuBw=.400098d4-1202-4aad-8101-da970c0c1cf5@github.com>

On Thu, 11 Aug 2022 10:02:56 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Smaller file sizes display one decimal precision

![FileChooser_Decimal_Precision](https://user-images.githubusercontent.com/107542245/184169593-4566db58-f0c4-4602-b89e-adb9345cec15.png)

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

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


From dnguyen at openjdk.org  Thu Aug 11 15:44:23 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Aug 2022 15:44:23 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v3]
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <Ri2xbcnclimZT23gmuJKv99el6plflAuFtIpEdn_EYA=.ae82af4f-8fb6-4e36-af2b-a1ffdb0cfc26@github.com>

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

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

  Updated AquaComboBoxUI to resize rectangle when editable. Updated test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9473/files
  - new: https://git.openjdk.org/jdk/pull/9473/files/1d888259..ffc44a89

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

  Stats: 35 lines in 2 files changed: 31 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9473.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9473/head:pull/9473

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


From dnguyen at openjdk.org  Thu Aug 11 15:47:40 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Aug 2022 15:47:40 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v4]
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

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

  Removed newline.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9473/files
  - new: https://git.openjdk.org/jdk/pull/9473/files/ffc44a89..4291d21e

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

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

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


From aturbanov at openjdk.org  Thu Aug 11 15:55:25 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 11 Aug 2022 15:55:25 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v4]
In-Reply-To: <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
Message-ID: <yqqrOwEH6gEU6FeZE0koMJFfIc_Fojcmm_pHQfzovfc=.c2b13075-ab66-4397-aee4-25ea645b2415@github.com>

On Thu, 11 Aug 2022 15:47:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed newline.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 471:

> 469:             }
> 470: 
> 471:             if(comboBox.getComponentOrientation().isLeftToRight()) {

Let's add a space after `if`

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

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


From honkar at openjdk.org  Thu Aug 11 15:59:29 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 11 Aug 2022 15:59:29 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v4]
In-Reply-To: <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
Message-ID: <APjTHVP5eXWUNyYQxu6-Ksdfu-LP1qi8fuRwVm8ZZaA=.8a98be15-8877-468d-8825-5dde2ee01b84@github.com>

On Thu, 11 Aug 2022 15:47:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed newline.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 458:

> 456:     class AquaComboBoxLayoutManager extends BasicComboBoxUI.ComboBoxLayoutManager {
> 457:         protected Rectangle rectangleForCurrentValue() {
> 458:             System.out.println("rectForCurrentValue NEW: " + comboBox.getHeight());

Missed removing print statement :)

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

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


From honkar at openjdk.org  Thu Aug 11 16:06:31 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 11 Aug 2022 16:06:31 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v4]
In-Reply-To: <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
Message-ID: <WIXTdArnXpds_hqMOLEKfSaYkVioFkbY-g1G77q2dMM=.495d9af0-8fff-4f5c-a77a-7b9014fae44a@github.com>

On Thu, 11 Aug 2022 15:47:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed newline.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 460:

> 458:             System.out.println("rectForCurrentValue NEW: " + comboBox.getHeight());
> 459:             int width = comboBox.getWidth();
> 460:             int height = 21;

Is this a Aqua LAF constraint on max height of text-field?

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

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


From dnguyen at openjdk.org  Thu Aug 11 16:43:29 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Aug 2022 16:43:29 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

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

  Removed comment. Added space.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9473/files
  - new: https://git.openjdk.org/jdk/pull/9473/files/4291d21e..78db9fbe

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

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

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


From dnguyen at openjdk.org  Thu Aug 11 16:43:32 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Aug 2022 16:43:32 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v4]
In-Reply-To: <APjTHVP5eXWUNyYQxu6-Ksdfu-LP1qi8fuRwVm8ZZaA=.8a98be15-8877-468d-8825-5dde2ee01b84@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
 <APjTHVP5eXWUNyYQxu6-Ksdfu-LP1qi8fuRwVm8ZZaA=.8a98be15-8877-468d-8825-5dde2ee01b84@github.com>
Message-ID: <M_ykfQaJun9654eWIyR4ZQSu4KjlWnqYfrgKgE5hmO4=.43965cbb-06f1-4d61-a564-a8f2ea474eb0@github.com>

On Thu, 11 Aug 2022 15:55:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed newline.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 458:
> 
>> 456:     class AquaComboBoxLayoutManager extends BasicComboBoxUI.ComboBoxLayoutManager {
>> 457:         protected Rectangle rectangleForCurrentValue() {
>> 458:             System.out.println("rectForCurrentValue NEW: " + comboBox.getHeight());
> 
> Missed removing print statement :)

Fixed. Thanks for catching that. I had a lot of comments to clean up after testing and this one slipped through.

> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 460:
> 
>> 458:             System.out.println("rectForCurrentValue NEW: " + comboBox.getHeight());
>> 459:             int width = comboBox.getWidth();
>> 460:             int height = 21;
> 
> Is this a Aqua LAF constraint on max height of text-field?

This height limitation is set to match the appearance of a non-oversized font in an editable JComboBox. I tested different values, and this value matches the appearance of an editable JComboBox when the AquaLookAndFeel control font is used.

The reason for overriding this method is to set this max height and condense the logic for the editor rectangle values. Previously, this class hard coded adjustments for the width and height values of the editor rectangle in layoutContainer when editor != null. This occurs right after this rectangleForCurrentValue is called, and this method is only used to calculate the rectangle position. So, overriding this method makes more sense since it does exactly that for Aqua L&F values specifically.

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

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


From dnguyen at openjdk.org  Thu Aug 11 16:43:33 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Aug 2022 16:43:33 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v4]
In-Reply-To: <yqqrOwEH6gEU6FeZE0koMJFfIc_Fojcmm_pHQfzovfc=.c2b13075-ab66-4397-aee4-25ea645b2415@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <IxQwYg2T5GVjPUIu3hFrWolw0U9xzvGK0LHbC4rosIE=.4409634e-6886-4f11-afd7-55d983839334@github.com>
 <yqqrOwEH6gEU6FeZE0koMJFfIc_Fojcmm_pHQfzovfc=.c2b13075-ab66-4397-aee4-25ea645b2415@github.com>
Message-ID: <mBq6WNkaAwd8QECGw5xHGLNEbRxq_VmCufLGUjHSZhA=.b8cb741d-1f1f-44c6-a5f0-7591eb036ddc@github.com>

On Thu, 11 Aug 2022 15:53:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed newline.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 471:
> 
>> 469:             }
>> 470: 
>> 471:             if(comboBox.getComponentOrientation().isLeftToRight()) {
> 
> Let's add a space after `if`

Fixed.

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

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


From dnguyen at openjdk.org  Thu Aug 11 16:47:36 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 11 Aug 2022 16:47:36 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
Message-ID: <aiGrm0biUjAb0wZAsbR2fW7bvKYjGeNoYug1MLvOk3A=.5f43448f-0636-4ddd-a73c-580381cb955f@github.com>

On Thu, 11 Aug 2022 16:43:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed comment. Added space.

@andy-goryachev-oracle I took into consideration your comment regarding RTL and LTR behavior regarding JComboBoxes. I did the testing as we briefly discussed and all results led me to believe Aqua L&F combo boxes only supported the button being on the right. Will still need to check with a device natively set to RTL, but it turns out a nearly decade old JBS issue already exists for this JComboBox button issue. I'll leave that separate from this PR and possibly look into that other issue later.

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

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


From prr at openjdk.org  Thu Aug 11 19:13:32 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:13:32 GMT
Subject: RFR: 7189422: [macosx] Submenu's arrow have a wrong position
In-Reply-To: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
References: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
Message-ID: <7KAEGg1Yf4jHEgwU6F-ffgcUtt7a68cTeJQB3J-SsTo=.cfc55c57-fb63-4408-9661-c874bc43351e@github.com>

On Fri, 5 Aug 2022 08:58:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is Arrow in submenu with empty title have a wrong position in Aqua L&F as can be seen
> 
> <img width="94" alt="image" src="https://user-images.githubusercontent.com/43534309/183023538-de8e51b4-31e6-45d7-b2bd-35da5e29c1e8.png">
> 
> 
> which is because the text being null/empty, `labelR` rectangle width/height is 0 so arrowIcon y coordinate becomes -ve as per the calculation in layoutMenuItem(). Although it seems logical to me to not show the arrow if submenu text is null, but
> whereas for other L&F, it is shown as this 
> for Metal
> <img width="83" alt="image" src="https://user-images.githubusercontent.com/43534309/183022436-d9e8ebf1-98de-4cf6-bf43-3713357846e5.png">
> 
> for Nimbus
> <img width="77" alt="image" src="https://user-images.githubusercontent.com/43534309/183022730-35d170b2-71c6-4231-9a03-880107dc49c6.png">
> 
> so the fix is made in Aqua L&F to show as other L&F as
> <img width="92" alt="image" src="https://user-images.githubusercontent.com/43534309/183023030-7356086d-957c-4e0d-bd52-bdf3493a96b0.png">

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Aug 11 19:13:33 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:13:33 GMT
Subject: RFR: 8292244: Remove unnecessary include directories
In-Reply-To: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
References: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
Message-ID: <Xvo-sugPTFBwrFrfNcVAnkc6SEfw0wYRw5qqttMs32Q=.094b38cd-3bc8-446d-b974-0fb51f55de6c@github.com>

On Thu, 11 Aug 2022 09:56:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove `java.base:include` from `EXTRA_HEADER_DIRS`.
> 
> The directory contains base versions of the files present in `<build>/support/modules_include/java.base`; the latter is automatically [included in every JDK library build](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L434).
> 
> Verified that:
> - cl.exe command line contains `-I<stuff>/modules_include/java.base`
> - Windows, Linux and Mac builds still pass

fine by me since as long as it really builds this is OK.

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

Marked as reviewed by prr (Reviewer).

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


From prr at openjdk.org  Thu Aug 11 19:13:42 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:13:42 GMT
Subject: RFR: 8291266: RenderPerfTest: missing content while rendering some
 primitives [v2]
In-Reply-To: <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
 <cZYbTBOMgoaFFtV7Mii5kFgM03fvayT8UJxE4db7FAM=.1e823282-612f-449b-97af-951e01132498@github.com>
Message-ID: <9h3wAtQcPqyfHw8XlC01z0zgaW4VuUlVa6a1V8M3pUU=.87b3346b-708b-4bfb-8f27-cb8b7f96395b@github.com>

On Fri, 5 Aug 2022 18:01:26 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Do not cause redundant endEncoder calls with batch processing of drawing primitives
>
> Alexey Ushakov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8291266: RenderPerfTest: missing content while rendering some primitives
>   
>   Added regression test

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Aug 11 19:13:45 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:13:45 GMT
Subject: RFR: 8291640: java/beans/XMLDecoder/8028054/Task.java should use
 the 3-arg Class.forName [v2]
In-Reply-To: <71HaGffpxBkDKSvH7w9801yUv8-uEmwOPNjbD-Zij0g=.7a0fe82a-a507-4a0f-bda9-203fb075c2cc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
 <71HaGffpxBkDKSvH7w9801yUv8-uEmwOPNjbD-Zij0g=.7a0fe82a-a507-4a0f-bda9-203fb075c2cc@github.com>
Message-ID: <bpp86OwazwpkqA1Pw_C13xpc0WoJhtP9f5ji24zVQH8=.5b20f779-e28e-41a9-9ef0-6986e1012e9d@github.com>

On Fri, 5 Aug 2022 02:25:11 GMT, Ao Qi <aoqi at openjdk.org> wrote:

>> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
>> 
>> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
>> 
>> 
>> --------------------------------------------------
>> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
>> ...
>> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
>> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
>> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
>> 	... 9 more
>> ...
>> 
>> --------------------------------------------------
>> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
>> ...
>> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
>> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
>> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
>> 	... 9 more
>> ...
>> --------------------------------------------------
>
> Ao Qi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert test/jdk/java/beans/XMLDecoder modification by 8284161

Marked as reviewed by prr (Reviewer).

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

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


From prr at openjdk.org  Thu Aug 11 19:14:23 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:14:23 GMT
Subject: RFR: 8288415: java/awt/PopupMenu/PopupMenuLocation.java is
 unstable in MacOS machines [v3]
In-Reply-To: <_QZn2bxW_yYgszpflq8_8fwIw0I_rn-IQPAnU56eggc=.e0c0ed19-66c7-47c2-a8c7-f03447cc2db1@github.com>
References: <pClI2zW5gi4TBiMW2CeftBlBN_p5Z7KWF4fpeVZqtlg=.e332bcae-1242-4227-8804-9ae8f0576381@github.com>
 <Oq-1maRzr3_IDJJ6tzPK-WI_Tb25751Dq2VlOAfuvAk=.ef1eb442-03df-40ef-8e87-0c5d00096b97@github.com>
 <_QZn2bxW_yYgszpflq8_8fwIw0I_rn-IQPAnU56eggc=.e0c0ed19-66c7-47c2-a8c7-f03447cc2db1@github.com>
Message-ID: <RVykK9gPv1EElMI1q0Vqv7LFBIQSmingw4vXUN7dq2c=.9fdbbfdd-1a06-4f2e-afa4-ce79a5d7e023@github.com>

On Fri, 15 Jul 2022 20:58:41 GMT, Phil Race <prr at openjdk.org> wrote:

>> Manukumar V S has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments fixed: Reverted variable name change, reverted +20 in point
>
> test/jdk/java/awt/PopupMenu/PopupMenuLocation.java line 130:
> 
>> 128:         robot.waitForIdle();
>> 129:         if (!actionEventReceivedLatch.await(5, TimeUnit.SECONDS)) {
>> 130:             captureScreen();
> 
> So if it hasn't passed in 5 seconds, you fail the test. How is that improving stability ?

ping ?

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

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


From prr at openjdk.org  Thu Aug 11 19:14:23 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:14:23 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS [v2]
In-Reply-To: <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
Message-ID: <Q0Gm1lvoCK9SKmdix7QsiEQu8CmrZg7F4iUDBylcIjU=.b6dbf307-c7f3-43a5-b288-9b765dd10c57@github.com>

On Mon, 1 Aug 2022 14:30:54 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
>> 
>> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
>> 
>> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made DrawRotatedStringUsingRotatedFont.java headful and dropped extra test

maybe @avu can be the 2nd reviewer ?

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

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


From prr at openjdk.org  Thu Aug 11 19:26:38 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:26:38 GMT
Subject: RFR: 8286313 [macos] Voice over reads the boolean value as null in
 the JTable
In-Reply-To: <wKAG5GQn5ANeVTnldjLG9ZUnz4mp0vtvLrK94Ft55HU=.3271c96b-cb54-422a-9759-18b811e44f23@github.com>
References: <wKAG5GQn5ANeVTnldjLG9ZUnz4mp0vtvLrK94Ft55HU=.3271c96b-cb54-422a-9759-18b811e44f23@github.com>
Message-ID: <QZVTq1TOjNT4lfwNIVay1KDzvOAayvHtz5IVCiBL02U=.f498383c-e534-4565-9302-7e9e0e4358f1@github.com>

On Mon, 25 Jul 2022 16:24:15 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> I have a Table which is extended from AbstractTableModel with String, integer and Boolean values ( to represent checkbox). When the row is selected Voice over reads the Boolean value as null. 
> 
> @azuev-java @mrserb @prrace please review.

I have only a fuzzy grasp of what this code is doing overall, but I interpret the change
as falling back to a different field for the text to speak if there's no value for the first field being tried .. which I presume is the case for a boolean .. so it seems like it can't hurt.

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

Marked as reviewed by prr (Reviewer).

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


From jwaters at openjdk.org  Thu Aug 11 19:31:06 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 11 Aug 2022 19:31:06 GMT
Subject: Integrated: 8291959: FileFontStrike#initNative does not properly
 initialize IG Table on Windows
In-Reply-To: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
References: <pZWgaQFx4Iz26y6HvyGNoSq2SU_d7IIj3MawWCSmUYQ=.7ec2726a-db0a-4401-83dc-ae4c4ae1cd26@github.com>
Message-ID: <0IAn-WnnBLXVM35ngV-Uk1al1dsq3q-HpjNRLzY2ong=.afd4ad50-9508-44a5-8619-bd3d7c66c9e0@github.com>

On Fri, 5 Aug 2022 09:46:13 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> FileFontStrike#initNative calls memset with LCDLUTCOUNT (the maximum length) as the number of bytes to zero out, which is incorrect as the elements are not 1 byte in size (unsigned char*), and will result in only part of the IG Table being correctly zeroed. This is more correctly resolved by passing sizeof igLUTable to memset instead.

This pull request has now been integrated.

Changeset: 3d20a8b2
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d20a8b20a636e4c11ad1568b011191726b45b90
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8291959: FileFontStrike#initNative does not properly initialize IG Table on Windows

Reviewed-by: prr

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

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


From aoqi at openjdk.org  Thu Aug 11 19:33:49 2022
From: aoqi at openjdk.org (Ao Qi)
Date: Thu, 11 Aug 2022 19:33:49 GMT
Subject: Integrated: 8291640: java/beans/XMLDecoder/8028054/Task.java should
 use the 3-arg Class.forName
In-Reply-To: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
References: <CmGslLounS216V0dIIR2CJ14mlwDo9yiACbE1oXiBSo=.9c428593-dc41-497d-bc3d-f5240e2e35dc@github.com>
Message-ID: <8k2w2J_0xfbC0KfluKMFRs5TzsD14KfA8aWw7An9SEU=.a5d144f3-dc9b-4c71-8ac6-68b6b3d8f427@github.com>

On Mon, 1 Aug 2022 16:23:59 GMT, Ao Qi <aoqi at openjdk.org> wrote:

> The issue comes from https://github.com/openjdk/jdk/pull/9677#issuecomment-1200811357. 
> 
> If Loom is not supported, two XMLDecoder tests would fail. The issue could be reproduced by zero, for example:
> 
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestConstructorFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> 
> --------------------------------------------------
> TEST: java/beans/XMLDecoder/8028054/TestMethodFinder.java
> ...
> Caused by: java.lang.UnsupportedOperationException: VM does not support continuations
> 	at java.base/jdk.internal.vm.ContinuationSupport.ensureSupported(ContinuationSupport.java:49)
> 	at java.base/jdk.internal.vm.Continuation.<clinit>(Continuation.java:52)
> 	... 9 more
> ...
> --------------------------------------------------

This pull request has now been integrated.

Changeset: dedc05cb
Author:    Ao Qi <aoqi at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dedc05cb40617f7b7e2cc235528b1892dcba4cd3
Stats:     5 lines in 3 files changed: 1 ins; 0 del; 4 mod

8291640: java/beans/XMLDecoder/8028054/Task.java should use the 3-arg Class.forName

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb, prr

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

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


From prr at openjdk.org  Thu Aug 11 19:35:41 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:35:41 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
Message-ID: <MiKWVJP-R9qTb7W9Lg3aM4qZIPjrSCJOfpshG-4MoYE=.293f327e-65e9-402e-9341-159fef76704f@github.com>

On Thu, 11 Aug 2022 10:02:56 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Smaller file sizes display one decimal precision

Changes requested by prr (Reviewer).

src/java.desktop/share/classes/sun/swing/FilePane.java line 1209:

> 1207:                     }
> 1208:                     text = mf.format(objs);
> 1209:                 } else if (len < 100L) {

we can never reach here, can we ? And isn't it obsolete ?

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

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


From aivanov at openjdk.org  Thu Aug 11 19:35:48 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Aug 2022 19:35:48 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
Message-ID: <ZHfzKxA2t_QNuP4GzTEcm5c9vFUGb8xYgey8kVAseuA=.a1134e86-de4d-4a6e-ada7-892bbb0b006f@github.com>

On Thu, 11 Aug 2022 10:02:56 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Smaller file sizes display one decimal precision

Also, please update the copyright year in `FilePane.java`.

src/java.desktop/share/classes/sun/swing/FilePane.java line 535:

> 533:         gigaByteString = UIManager.getString("FileChooser.fileSizeGigaBytes", l);
> 534:         fullRowSelection = UIManager.getBoolean("FileView.fullRowSelection");
> 535: 

Can this blank line remain?

src/java.desktop/share/classes/sun/swing/FilePane.java line 1129:

> 1127:         double baseFileSize = 1000.0;
> 1128:         MessageFormat mf = new MessageFormat("");
> 1129:         NumberFormat nf = NumberFormat.getNumberInstance();

All three can be `final`.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1199:

> 1197:             } else if (value instanceof Long len) {
> 1198:                 if (listViewWindowsStyle) {
> 1199:                     updateMessageFormatPattern(kiloByteString, 1);

Now you always call `updateMessageFormatPattern` with 1 as the second parameter. Maybe you could initialise both MessageFormat and NumberFormat once and then just use the objects. Or switch back to `MessageFormat.format` method.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1206:

> 1204:                     } else {
> 1205:                         double kbVal = formatToDoubleValue(len);
> 1206:                         objs[0] = Double.valueOf(kbVal);

You can assign `double` directly without explicit boxing with `Double.valueOf`.

Suggestion:

                        objs[0] = 0.0;
                    } else if (len > 0 && len < 100L) {
                        objs[0] = 0.1;
                    } else {
                        objs[0] = formatToDoubleValue(len);


IDE highlights each line with such usage.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 50:

> 48:     private static JFrame frame;
> 49:     private static JFileChooser fc;
> 50:     private static PassFailJFrame passFailJFrame;

These three fields can be local variables.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 51:

> 49:     private static JFileChooser fc;
> 50:     private static PassFailJFrame passFailJFrame;
> 51:     private static Path [] tempFilePaths;

Suggestion:

    private static Path[] tempFilePaths;


No space before brackets in array declaration. In other places too.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 78:

> 76:         PassFailJFrame.positionTestWindow(frame, PassFailJFrame.Position.HORIZONTAL);
> 77:         // create temp files
> 78: 

The comment applies to `try` block. The blank line should be above the comment. Please start comments with a capital letter.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 98:

> 96:     }
> 97: 
> 98:     public static void main(String args[]) throws InterruptedException,

Use Java-style array declarations:
Suggestion:

    public static void main(String[] args) throws InterruptedException,

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

Changes requested by aivanov (Reviewer).

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


From prr at openjdk.org  Thu Aug 11 19:36:58 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 11 Aug 2022 19:36:58 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <g3DXiPCimcobH6YWx2asNlI-hqXPmY6l6m_k8uvbqXM=.6bb2e941-51d2-4d0e-a4d7-d5bde6965fda@github.com>

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

Marked as reviewed by prr (Reviewer).

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

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


From aivanov at openjdk.org  Thu Aug 11 19:39:03 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Aug 2022 19:39:03 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <MiKWVJP-R9qTb7W9Lg3aM4qZIPjrSCJOfpshG-4MoYE=.293f327e-65e9-402e-9341-159fef76704f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
 <MiKWVJP-R9qTb7W9Lg3aM4qZIPjrSCJOfpshG-4MoYE=.293f327e-65e9-402e-9341-159fef76704f@github.com>
Message-ID: <8lHo1rsec5xI6GN2valYvFnThPcH0cVvTIlTY0UhbuM=.14b550ad-827e-4468-8d1e-1900e05cd3f2@github.com>

On Thu, 11 Aug 2022 19:30:18 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Smaller file sizes display one decimal precision
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1209:
> 
>> 1207:                     }
>> 1208:                     text = mf.format(objs);
>> 1209:                 } else if (len < 100L) {
> 
> we can never reach here, can we ? And isn't it obsolete ?

It's reachable when `listViewWindowsStyle` is `false`, which seems to be the case in all the Look-and-Feels but Windows one.

Yet it looks confusing.

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

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


From aivanov at openjdk.org  Thu Aug 11 21:05:12 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Aug 2022 21:05:12 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v7]
In-Reply-To: <7LseSaW3LzlWZ3gtvT061JDQMI_g72UKECV757dMfh4=.12b1775f-6560-4fcb-b2ff-d56a7a35841b@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7LseSaW3LzlWZ3gtvT061JDQMI_g72UKECV757dMfh4=.12b1775f-6560-4fcb-b2ff-d56a7a35841b@github.com>
Message-ID: <NXJJY4mv0TC7yf8m7hEhNtm51glRpsZrSHia5WEoxPQ=.6a331d5d-99e4-4ab9-b598-8d746953d39f@github.com>

On Fri, 5 Aug 2022 23:50:57 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   helper method added to sync location

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

> 311:             syncLocationToWindowManager();
> 312:             if (testWindow != null) {
> 313:                 testWindow.setLocation(frame.getX(),

Just a thought: Should the window be centered to the instruction frame rather left-aligned?

Left-aligned is simpler, it could be easier to scan too.

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

> 328: 
> 329:     // this method pushes the updated frame location to window manager
> 330:     // before it is used to reposition the test window.

Make it javadoc, so that when you hover over the method, the IDE shows you description of the method.

>From our discussions, it is to ensure the frame location is updated _by the window manager_ if it adjusts the frame location.

test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 51:

> 49:     public static void createAndShowGUI() {
> 50: 
> 51:             frame = new JFrame("JTabbedPane");

Shall the indentation be adjusted? Four spaces to the left?

test/jdk/javax/swing/JTabbedPane/4209065/bug4209065.java line 77:

> 75:         passFailJFrame.awaitAndCheck();
> 76:     }
> 77: }

Let us add the final line break.

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

> 71:         // Arrange the test instruction frame and test frame side by side
> 72:         PassFailJFrame.positionTestWindow(f, PassFailJFrame.Position.HORIZONTAL);
> 73:         f.setVisible(true);

It should be called on EDT if `f` is a `JFrame`.

And `positionTestWindow` should be too because the instruction frame is a `JFrame`. Yet it complicates the code a lot. Dealing with `positionTestWindow` could and should be postponed, it was overlooked or as its javadoc says it was to be called from EDT.

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

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


From honkar at openjdk.org  Thu Aug 11 22:27:39 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 11 Aug 2022 22:27:39 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v8]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

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

  review changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/ccb87876..0567db94

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

  Stats: 47 lines in 3 files changed: 15 ins; 13 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

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


From honkar at openjdk.org  Thu Aug 11 22:27:47 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 11 Aug 2022 22:27:47 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v7]
In-Reply-To: <NXJJY4mv0TC7yf8m7hEhNtm51glRpsZrSHia5WEoxPQ=.6a331d5d-99e4-4ab9-b598-8d746953d39f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7LseSaW3LzlWZ3gtvT061JDQMI_g72UKECV757dMfh4=.12b1775f-6560-4fcb-b2ff-d56a7a35841b@github.com>
 <NXJJY4mv0TC7yf8m7hEhNtm51glRpsZrSHia5WEoxPQ=.6a331d5d-99e4-4ab9-b598-8d746953d39f@github.com>
Message-ID: <B5SAFWPndaWY1onHlGEnxlgM1SV0onGeEI29rWlheqA=.b952c9f7-f970-41b1-a218-53fcf4f842e9@github.com>

On Thu, 11 Aug 2022 20:36:48 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   helper method added to sync location
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 313:
> 
>> 311:             syncLocationToWindowManager();
>> 312:             if (testWindow != null) {
>> 313:                 testWindow.setLocation(frame.getX(),
> 
> Just a thought: Should the window be centered to the instruction frame rather left-aligned?
> 
> Left-aligned is simpler, it could be easier to scan too.

I think left-aligned is simpler :)
Centering would complicate the code and might be an overkill in this context.

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

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


From duke at openjdk.org  Thu Aug 11 22:51:28 2022
From: duke at openjdk.org (Martin Desruisseaux)
Date: Thu, 11 Aug 2022 22:51:28 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode()
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <5I2W991_1UWaHsGqyes0upSaWxnzibaNdr0TkXb2emI=.d59d4907-c3fa-4a4a-a1d7-45bb66010b86@github.com>

On Fri, 10 Jun 2022 09:39:48 GMT, Martin Desruisseaux <duke at openjdk.org> wrote:

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

src/java.desktop/share/classes/java/awt/geom/AffineTransform.java line 3916:

> 3914:     /**
> 3915:      * Returns a hash code for the given value, with negative zero
> 3916:      * collapsed into to the single positive zero.

Should I fix this trivial typo before the merge? ("into to" ? "to").

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

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


From djelinski at openjdk.org  Fri Aug 12 05:26:21 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 12 Aug 2022 05:26:21 GMT
Subject: Integrated: 8292244: Remove unnecessary include directories
In-Reply-To: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
References: <Phvn8qW_L7X_-pobJY4lceY5t8fOY9jXHj9WqmYLuY0=.dbe27f48-711c-4374-9f8a-1faf89af946c@github.com>
Message-ID: <ZEEogF2mEtCfPFthB5NkDwMUeXXUlqHIMZjYHEYRhqc=.181b4965-1fad-404f-8c76-a3b76f558ad3@github.com>

On Thu, 11 Aug 2022 09:56:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Remove `java.base:include` from `EXTRA_HEADER_DIRS`.
> 
> The directory contains base versions of the files present in `<build>/support/modules_include/java.base`; the latter is automatically [included in every JDK library build](https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L434).
> 
> Verified that:
> - cl.exe command line contains `-I<stuff>/modules_include/java.base`
> - Windows, Linux and Mac builds still pass

This pull request has now been integrated.

Changeset: 45e5b31a
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45e5b31a183e2ddca8f8d10a922b20af97efdaff
Stats:     6 lines in 2 files changed: 0 ins; 5 del; 1 mod

8292244: Remove unnecessary include directories

Reviewed-by: erikj, prr

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

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


From duke at openjdk.org  Fri Aug 12 08:16:19 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 12 Aug 2022 08:16:19 GMT
Subject: RFR: JDK-8292276 : Adds to CSS.java the missing color names.
Message-ID: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>

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)

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

Commit messages:
 - Adds to CSS.java the missing color names.

Changes: https://git.openjdk.org/jdk/pull/9825/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292276
  Stats: 314 lines in 1 file changed: 262 ins; 0 del; 52 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 psadhukhan at openjdk.org  Fri Aug 12 08:16:20 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Aug 2022 08:16:20 GMT
Subject: RFR: JDK-8292276 : Adds to CSS.java the missing color names.
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <qxlH-kLeMDYg0vwl3MNnJSlFwyo6BzPjkI9GyfC_7_U=.a16ee906-6498-4621-8b45-c719f2c81bb9@github.com>

On Wed, 10 Aug 2022 20:00:29 GMT, ScientificWare <duke at openjdk.org> wrote:

> 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)

First and foremost, you need to add JBS id 8292276 into the PR title. Also, please add a jtreg testcase which should fail before your fix and pass after.I guess JBS has a reproducer which can be made into a jtreg testcase, of which you can see several examples in jdk/test/javax/swing directory.

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

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


From aturbanov at openjdk.org  Fri Aug 12 08:55:58 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 12 Aug 2022 08:55:58 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
Message-ID: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>

Field `keyListener` was added under [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its usages were removed in [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)

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

Commit messages:
 - [PATCH] Unused field 'keyListener' in BasicRadioButtonUI

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

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


From avu at openjdk.org  Fri Aug 12 09:47:34 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 12 Aug 2022 09:47:34 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS [v2]
In-Reply-To: <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
Message-ID: <QhZgsRaNXqRet5_APbtadDk-y93x1P4mBSARdevBtd4=.809bca08-1ba5-4995-8720-da0d13bec99f@github.com>

On Mon, 1 Aug 2022 14:30:54 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
>> 
>> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
>> 
>> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made DrawRotatedStringUsingRotatedFont.java headful and dropped extra test

Marked as reviewed by avu (Committer).

Yes, I've looked through the code. It looks good to me.

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

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


From duke at openjdk.org  Fri Aug 12 09:51:35 2022
From: duke at openjdk.org (ExE Boss)
Date: Fri, 12 Aug 2022 09:51:35 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS.
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <KSitJcTkN4kk47Tz_VuokCZTZvr3dF5DyBcRJtnzuKg=.054441cf-0f4b-415e-9f03-f3b12434790f@github.com>

On Wed, 10 Aug 2022 20:00:29 GMT, ScientificWare <duke at openjdk.org> wrote:

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1703:

> 1701:             color = hexToColor("#f5f5f5");
> 1702:         else if (str.equalsIgnoreCase("Yellowgreen"))
> 1703:             color = hexToColor("#9acd32");

This?should probably?use <code>switch([str.toLowerCase][String::toLowerCase]([Locale.ROOT]))</code> instead?of a?linear?search.

[String::toLowerCase]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/String.html#toLowerCase(java.util.Locale)
[Locale.ROOT]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/Locale.html#ROOT

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

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


From avu at openjdk.org  Fri Aug 12 09:53:30 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Fri, 12 Aug 2022 09:53:30 GMT
Subject: Integrated: 8291266: RenderPerfTest: missing content while rendering
 some primitives
In-Reply-To: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
References: <2sbBEDbZFOfmucRtW04ubMNgP6Ss4-WWWQrdMupFqRA=.babed540-5b5c-4227-a7b4-a8a52ae3083f@github.com>
Message-ID: <jUJBWoVF0Vzi1AEWZHbl8NUt9zDWUJzeo6wD65DOVJY=.6e5df643-c3f6-4a2d-9ebb-6bdc17e43bdb@github.com>

On Thu, 4 Aug 2022 21:07:02 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Do not cause redundant endEncoder calls with batch processing of drawing primitives

This pull request has now been integrated.

Changeset: 871b7dab
Author:    Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/871b7dab143fd92f14724563d448126a537fa5d1
Stats:     156 lines in 2 files changed: 154 ins; 0 del; 2 mod

8291266: RenderPerfTest: missing content while rendering some primitives

Reviewed-by: aghaisas, prr

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

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


From duke at openjdk.org  Fri Aug 12 10:09:13 2022
From: duke at openjdk.org (ScientificWare)
Date: Fri, 12 Aug 2022 10:09:13 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS.
In-Reply-To: <KSitJcTkN4kk47Tz_VuokCZTZvr3dF5DyBcRJtnzuKg=.054441cf-0f4b-415e-9f03-f3b12434790f@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <KSitJcTkN4kk47Tz_VuokCZTZvr3dF5DyBcRJtnzuKg=.054441cf-0f4b-415e-9f03-f3b12434790f@github.com>
Message-ID: <XmqPrA-QEf4jIU9exGmB9UX6mWn2fF9Myw_suUA6YOQ=.13e47c93-8eb2-4479-b6fb-236f6b18c4aa@github.com>

On Fri, 12 Aug 2022 09:48:54 GMT, ExE Boss <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1703:
> 
>> 1701:             color = hexToColor("#f5f5f5");
>> 1702:         else if (str.equalsIgnoreCase("Yellowgreen"))
>> 1703:             color = hexToColor("#9acd32");
> 
> This?should probably?use <code>switch([str.toLowerCase][String::toLowerCase]([Locale.ROOT]))</code> instead?of a?linear?search.
> 
> [String::toLowerCase]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/String.html#toLowerCase(java.util.Locale)
> [Locale.ROOT]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/Locale.html#ROOT

Hi @ExE-Boss, Thanks for reviewing, I made several propositions here https://github.com/scientificware/jdk/issues/12.

Including switch usage with direct Color generating.
The last on is to move this logic to Color.java.

May I have your comments about them ?

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

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


From psadhukhan at openjdk.org  Fri Aug 12 12:07:14 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 12 Aug 2022 12:07:14 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
Message-ID: <0G0zF5bYaz6Yu2zRZHmbuYTSqQgWacbkdORWMvN7O-0=.2a330d4d-41b9-4e03-b8e2-76b99e45dc8d@github.com>

On Thu, 11 Aug 2022 16:43:29 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed comment. Added space.

I am not sure if this is correct approach...
Have you seen any macos documentation citing combobox height should not increase even if font size change? 
That might be problematic for say, accessibility usecase, for slight visually impaired more hearing impaired, where we need to draw them big, right?

So, assuming it's a issue, I think
Since textField height changes with font size, why can't we use the same rectangleForCurrentValue() with which we draw the textField height, for arrowButton height
 as seen here (https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java#L470)

I see that we call [AquaCombobBoxButton](https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java#L163) with `height`. 
Are you saying this height, even you change according to font size,  is ignored?

Then it seems this painter.paint() which calls AquaPainter.paintFromSingleCachedImage() which calls MultiResolutionCachedImage to create a MRI maybe is not creating proper MRI image as per the given arrowbutton size.
Can you find out why?  

Maybe non-editable combobox can have "single cached image" to have single-sized arrowbutton, but it may not be correct for editable combobox where font size can be changed 
OR maybe non-editable combobox not changing height for diff. fontsize, also is a result of the above MRI creation issue.

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

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


From aivanov at openjdk.org  Fri Aug 12 13:37:15 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 12 Aug 2022 13:37:15 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v8]
In-Reply-To: <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
Message-ID: <B-Gr9UpMApbmqNBJrHvMOP1mYmMhmGgcl_fscxzlEh8=.2dc8e42d-ee50-4e71-8295-0fbb1da85d2e@github.com>

On Thu, 11 Aug 2022 22:27:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

Marked as reviewed by aivanov (Reviewer).

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

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


From duke at openjdk.org  Fri Aug 12 14:51:27 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Aug 2022 14:51:27 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <ZHfzKxA2t_QNuP4GzTEcm5c9vFUGb8xYgey8kVAseuA=.a1134e86-de4d-4a6e-ada7-892bbb0b006f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
 <ZHfzKxA2t_QNuP4GzTEcm5c9vFUGb8xYgey8kVAseuA=.a1134e86-de4d-4a6e-ada7-892bbb0b006f@github.com>
Message-ID: <WxMoedi05KK_6C5hkO-7geMmCkxGSK2113_Qc3eZcus=.d167ed80-18ca-4531-a795-eecefeac1f44@github.com>

On Thu, 11 Aug 2022 19:11:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Smaller file sizes display one decimal precision
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1199:
> 
>> 1197:             } else if (value instanceof Long len) {
>> 1198:                 if (listViewWindowsStyle) {
>> 1199:                     updateMessageFormatPattern(kiloByteString, 1);
> 
> Now you always call `updateMessageFormatPattern` with 1 as the second parameter. Maybe you could initialise both MessageFormat and NumberFormat once and then just use the objects. Or switch back to `MessageFormat.format` method.

MessageFormat.format method was truncating "0" from values like "0.0", "1.0" and so on.
Due to that I initialize MessageFormat and NumberFormat instance.

The first parameter in updateMessageFormatPattern  method changes based on file size, so calling it multiple times to update the pattern.
The second parameter can be removed.

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

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


From mkartashev at openjdk.org  Fri Aug 12 15:41:22 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 12 Aug 2022 15:41:22 GMT
Subject: Integrated: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS
In-Reply-To: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
Message-ID: <2nwUXnhDRc12vFiby9sYgS2dUW-DxWkiUKSepA1mj3Y=.5c3ac958-d199-41c0-ad73-9973fadbce4b@github.com>

On Mon, 4 Jul 2022 09:31:05 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
> 
> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
> 
> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.

This pull request has now been integrated.

Changeset: 00decca4
Author:    Maxim Kartashev <mkartashev at openjdk.org>
Committer: Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00decca46a77ea9390081655b069008aacfea525
Stats:     141 lines in 3 files changed: 120 ins; 5 del; 16 mod

8289208: Test DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS

Reviewed-by: prr, avu

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

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


From honkar at openjdk.org  Fri Aug 12 16:39:24 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 12 Aug 2022 16:39:24 GMT
Subject: RFR: 8288428: javax/swing/JInternalFrame/Test6505027.java fails
 frequently in MacOS 12 machines
In-Reply-To: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
References: <6YC8w4_hoAm0h7IlClKsyBdz0aJj2G_Z3hfQSifEpcM=.f720f5a5-565d-452c-8cd6-527ed4fc50ef@github.com>
Message-ID: <ZtcjqXtcm8zc-EKsiS03GDCsvriF-MzbK8AvI9KK4Qg=.3b0e5977-289e-4e25-af12-58b9cb1fa73b@github.com>

On Fri, 17 Jun 2022 14:28:15 GMT, Manukumar V S <mvs at openjdk.org> wrote:

> javax/swing/JInternalFrame/Test6505027.java seems to be unstable in MacOS machines, especially in MacOSX 12 machines and it fails intermittently in CI causing some noise.
> It seems to be a testbug as adding some stability improvements fix the issue.
> 
> Fix:
> Some stability improvements have been done and the test has been run 10 times per platform in mach5 and got full PASS.

Copyright year needs to be changed https://github.com/openjdk/jdk/blob/7995b9b9c63bbb76e44d0dbf7f180294afd87453/test/jdk/javax/swing/JInternalFrame/Test6505027.java#L2

Author tag in jtreg header is no longer used. It can be removed.

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

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


From duke at openjdk.org  Fri Aug 12 17:09:48 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 12 Aug 2022 17:09:48 GMT
Subject: RFR: 8292271 : Fix
 java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test
Message-ID: <gpnPCT4GfLO7w3w3uuUVk3BBehfPYJeFseqU2dZ_yZk=.69f0df8a-10a7-47da-9de0-3c7b269ab9f9@github.com>

1) This test was failing due to yesno 
test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno 
2) PrintCheckboxManualTest.html file was missing
3) Added os.family since test instruction says that its a linux and solair toolkit only test
4) Removed Sysout & TestDialog class &  added a better manual framework to show the instruction and test frame. 

@shurymury

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

Commit messages:
 - 8292271 : Fix java/awt/PrintJob/PrintCheckboxTest/PrintCheckboxManualTest.java test

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

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


From aivanov at openjdk.org  Fri Aug 12 18:37:24 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 12 Aug 2022 18:37:24 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <WxMoedi05KK_6C5hkO-7geMmCkxGSK2113_Qc3eZcus=.d167ed80-18ca-4531-a795-eecefeac1f44@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
 <ZHfzKxA2t_QNuP4GzTEcm5c9vFUGb8xYgey8kVAseuA=.a1134e86-de4d-4a6e-ada7-892bbb0b006f@github.com>
 <WxMoedi05KK_6C5hkO-7geMmCkxGSK2113_Qc3eZcus=.d167ed80-18ca-4531-a795-eecefeac1f44@github.com>
Message-ID: <X5_JVtet7WGrFuWytMguYnc9KuzlhNS6s1CtmzF3j_8=.b6688d00-b848-40f8-9d36-3c05137e90c2@github.com>

On Fri, 12 Aug 2022 14:49:18 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> MessageFormat.format method was truncating "0" from values like "0.0", "1.0" and so on. Due to that I initialize MessageFormat and NumberFormat instance.

Got it.

> The first parameter in updateMessageFormatPattern method changes based on file size, so calling it multiple times to update the pattern. The second parameter can be removed.

Right, it makes sense. Please remove the second parameter.

After the second parameter is removed, `NumberFormat` does not change though, so it can be initialised once.

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

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


From duke at openjdk.org  Fri Aug 12 18:41:35 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Aug 2022 18:41:35 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <X5_JVtet7WGrFuWytMguYnc9KuzlhNS6s1CtmzF3j_8=.b6688d00-b848-40f8-9d36-3c05137e90c2@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
 <ZHfzKxA2t_QNuP4GzTEcm5c9vFUGb8xYgey8kVAseuA=.a1134e86-de4d-4a6e-ada7-892bbb0b006f@github.com>
 <WxMoedi05KK_6C5hkO-7geMmCkxGSK2113_Qc3eZcus=.d167ed80-18ca-4531-a795-eecefeac1f44@github.com>
 <X5_JVtet7WGrFuWytMguYnc9KuzlhNS6s1CtmzF3j_8=.b6688d00-b848-40f8-9d36-3c05137e90c2@github.com>
Message-ID: <fl9CXAZy66BS3qCkglzLcm2bJumD9Jl_jMNOwOgLZZs=.b5e63aeb-2634-4a01-aeb9-b6f23fdea9d3@github.com>

On Fri, 12 Aug 2022 18:35:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> MessageFormat.format method was truncating "0" from values like "0.0", "1.0" and so on.
>> Due to that I initialize MessageFormat and NumberFormat instance.
>> 
>> The first parameter in updateMessageFormatPattern  method changes based on file size, so calling it multiple times to update the pattern.
>> The second parameter can be removed.
>
>> MessageFormat.format method was truncating "0" from values like "0.0", "1.0" and so on. Due to that I initialize MessageFormat and NumberFormat instance.
> 
> Got it.
> 
>> The first parameter in updateMessageFormatPattern method changes based on file size, so calling it multiple times to update the pattern. The second parameter can be removed.
> 
> Right, it makes sense. Please remove the second parameter.
> 
> After the second parameter is removed, `NumberFormat` does not change though, so it can be initialised once.

Yeah sure, I will remove the second parameter.

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

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


From duke at openjdk.org  Fri Aug 12 19:56:53 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Aug 2022 19:56:53 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v18]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <T9ZSV10BLXhCN5r4vg2_cZHBPP9LpInYjJEFzh6lLVw=.eec5131c-a2b7-4f7c-be6f-2970a4556016@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

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

  Updated as per suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/1d830a54..a5ae29c1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=16-17

  Stats: 50 lines in 2 files changed: 9 ins; 14 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

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


From duke at openjdk.org  Fri Aug 12 19:56:53 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Aug 2022 19:56:53 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <VUaQI-2OcXc_VryjznoG2M_7WrzzuP-9u0XVMJJux-c=.cd4822f9-afda-41d6-99d9-8289ce4f700e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
 <ybJzApQsTKCxFtGWIHNoCqdOm9F148KiBEAhG4IVis8=.25c24784-6d66-45eb-9d62-226277d81620@github.com>
 <HzVciOi9SjPDdYnoLy8T7LNsKsmtje3IWniUcwDXU_E=.b981ed88-841f-4b16-8d95-aa6237edc4ae@github.com>
 <VUaQI-2OcXc_VryjznoG2M_7WrzzuP-9u0XVMJJux-c=.cd4822f9-afda-41d6-99d9-8289ce4f700e@github.com>
Message-ID: <Q5EP39NCI8b7PsbJS3hXYxB4qz7HgHIy3zneYOmHFCo=.ac6de4f8-905a-43e1-944f-c69e1a4379db@github.com>

On Wed, 10 Aug 2022 18:39:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > > If we display the file size with one decimal point precision, then it doesn't hold at all until the file size reaches 1 KB.
>>> 
>>> Is your point ( pun intended) that it looks like we are displaying files to a decimal precision, but in fact are not ?
>>> 
>>> ie it is very odd to display 1.0kb for files of 100, 200, 300, etc bytes .. What is the reason for displaying them all as 1.0kb .. this review is so long I'm not sure I am following any more.
>>> 
>>> Could we get a summary in a few sentences of the entire current proposal and the justification for it ?
>> 
>> There was an issue with plural forms if we show file sizes in terms of bytes. So, it has been discussed that 
>> we can show the file size in terms of "1 KB" for files having size >0 and <1000 bytes. To keep file size similar to native file system, JFileChooser displays file sizes with one decimal point precision.
>> 
>> Now, the issue is whether an empty file should be displayed as "0.0 KB" or "0 KB" ? 
>> As of now empty files are displayed as "0 KB".
>
>> > > > If we display the file size with one decimal point precision, then it doesn't hold at all until the file size reaches 1 KB.
>> > 
>> > Is your point ( pun intended) that it looks like we are displaying files to a decimal precision, but in fact are not ?
> 
> That's exactly my point.
> 
> 
>> > Could we get a summary in a few sentences of the entire current proposal and the justification for it ?
> 
> I also asked for the summary. That time it was a bit different:
> https://github.com/openjdk/jdk/pull/9327#discussion_r939828467
> 
>> There was an issue with plural forms if we show file sizes in terms of bytes. So, it has been discussed that we can show the file size in terms of "1 KB" for files having size >0 and <1000 bytes. To keep file size similar to native file system, JFileChooser displays file sizes with one decimal point precision.
>> 
>> Now, the issue is whether an empty file should be displayed as "0.0 KB" or "0 KB" ? As of now empty files are displayed as "0 KB".
> 
> The original issue is that we displayed a zero-sized file as 1 KB. It's stated in the bug subject and in the bug description with more details.
> 
> The initial fix was to display it as 0 bytes, which leads to localisation problems, especially if we take into account 1 byte.
> 
> Eventually, it was decided to display the size in KB. Thus zero-sized file is displayed as 0 KB, and one-byte-sized file is displayed as 1 KB. This is fine.
> 
> Later on, the decimal point was added to mimic native file navigation app in Ubuntu. Now for files larger than 1 KB, the size is shown up to one decimal point. Yet all the files below 1 KB are still displayed as 1 KB. I think it is confusing. If we care to display the size with one decimal point for larger files, why can't we display the size of smaller files with the same precision?
> 
> So, 0 bytes is 0.0 KB; > 0 and <= 100 bytes is 0.1 KB, and so on.
> 
> Alternatively, drop the decimal altogether.

@aivanov-jdk  I have implemented the suggested changes.

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

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


From aivanov at openjdk.org  Fri Aug 12 20:08:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 12 Aug 2022 20:08:27 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v18]
In-Reply-To: <T9ZSV10BLXhCN5r4vg2_cZHBPP9LpInYjJEFzh6lLVw=.eec5131c-a2b7-4f7c-be6f-2970a4556016@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <T9ZSV10BLXhCN5r4vg2_cZHBPP9LpInYjJEFzh6lLVw=.eec5131c-a2b7-4f7c-be6f-2970a4556016@github.com>
Message-ID: <_J6PTXKPW_7GbjgNPB6Uni_KUXvM2zgmVcX8r5FG7uw=.6a95e86d-1bc6-46eb-9715-b09f53e9bd58@github.com>

On Fri, 12 Aug 2022 19:56:53 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per suggested changes

Marked as reviewed by aivanov (Reviewer).

src/java.desktop/share/classes/sun/swing/FilePane.java line 1187:

> 1185:             String text;
> 1186:             Object[] objs = new Object[1];
> 1187:             nf.setMinimumFractionDigits(1);

I'd rather put that into constructor. It's to be run once rather than each time `getTableCellRendererComponent` is called.

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

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


From dcubed at openjdk.org  Fri Aug 12 20:15:27 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 20:15:27 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS [v2]
In-Reply-To: <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
Message-ID: <QnUDYjLzCA_kFrYz93o3_-Z47C9_86p9EBokA0VqlKA=.ad3cf742-56c7-4a5d-9f82-f065db6f0916@github.com>

On Mon, 1 Aug 2022 14:30:54 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
>> 
>> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
>> 
>> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made DrawRotatedStringUsingRotatedFont.java headful and dropped extra test

This fix appears to be causing test failures in Tier3:

[JDK-8292304](https://bugs.openjdk.org/browse/JDK-8292304)
sun/java2d/Disposer/TestDisposerRace.java fails after JDK-8289208

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

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


From prr at openjdk.org  Fri Aug 12 20:21:44 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Aug 2022 20:21:44 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
Message-ID: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>

Thread.stop() and ThreadGroup.destroy() are called by sun.awt.AppContext.dispose()

These should no longer be called. Both are deprecated for removal.
ThreadGroup.destroy() does nothing. Thread.stop() throws UnsupportedOperationException
for virtual threads, and is expected to do so for all threads if it is not removed before then.

This fix stops calling these methods and prints a warning from dispose() to encourage
callers to move away from AppContext which itself will likely be removed in a future release
since the Webstart and Plugin scenarios that needed it are no longer supported.
Although most tests that use AppContext are now irrelevant only one test actually fails
and is removed  so we are doing the least here and the big job of completely getting rid of
AppContext is for another day.

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

Commit messages:
 - 8289616

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

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


From duke at openjdk.org  Fri Aug 12 20:22:30 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Aug 2022 20:22:30 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v19]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <U8BQDx3UEY2GYEoYklOJYqxtt39_2dFex6GWYQfMwaY=.3bf4de53-66df-48cd-afb2-6b82625704bc@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

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

  Updated as per review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/a5ae29c1..d749cc38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=17-18

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

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


From kizune at openjdk.org  Fri Aug 12 20:24:24 2022
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 12 Aug 2022 20:24:24 GMT
Subject: RFR: 8286313 [macos] Voice over reads the boolean value as null in
 the JTable
In-Reply-To: <wKAG5GQn5ANeVTnldjLG9ZUnz4mp0vtvLrK94Ft55HU=.3271c96b-cb54-422a-9759-18b811e44f23@github.com>
References: <wKAG5GQn5ANeVTnldjLG9ZUnz4mp0vtvLrK94Ft55HU=.3271c96b-cb54-422a-9759-18b811e44f23@github.com>
Message-ID: <_qn2yQHHTzZfZH5vUTCTm4RODV3GeTKZaQfdflyH3M0=.3e38c730-c3b3-4f87-a823-e19694a8e017@github.com>

On Mon, 25 Jul 2022 16:24:15 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> I have a Table which is extended from AbstractTableModel with String, integer and Boolean values ( to represent checkbox). When the row is selected Voice over reads the Boolean value as null. 
> 
> @azuev-java @mrserb @prrace please review.

Marked as reviewed by kizune (Reviewer).

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

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


From dcubed at openjdk.org  Fri Aug 12 20:37:33 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 20:37:33 GMT
Subject: RFR: 8292305: [BACKOUT] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
Message-ID: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>

This reverts commit 00decca46a77ea9390081655b069008aacfea525.

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

Commit messages:
 - 8292305: [BACKOUT] JDK-8289208 Test DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS

Changes: https://git.openjdk.org/jdk/pull/9864/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9864&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292305
  Stats: 146 lines in 3 files changed: 10 ins; 125 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/9864.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9864/head:pull/9864

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


From prr at openjdk.org  Fri Aug 12 20:42:20 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Aug 2022 20:42:20 GMT
Subject: RFR: 8289208: Test DrawRotatedStringUsingRotatedFont.java
 occasionally crashes on MacOS [v2]
In-Reply-To: <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
References: <GF-BCfB5qriM0It9dj7LMkhEtKBH-s9iQNV-WVV7GOg=.37b332ff-86ec-4154-b97b-0c64480845c8@github.com>
 <0y6Vc6xxyk2TFom5WhfBV6KuKGwgju5NQEDTD1uioZA=.02f0a642-7bcb-4317-bc51-9064d43a5f06@github.com>
Message-ID: <tMda79DZALozEO1TnGvwrA2AtBePgR63Shi-FSN2Rg4=.08cc5bfd-3e67-42f6-ae4a-3b1ec8241839@github.com>

On Mon, 1 Aug 2022 14:30:54 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> Java2D's `Disposer` maintains a record of objects to dispose of with the help of a collection that isn't thread safe. When `DisposerRecords` objects are being added to it at the same time as others are being disposed on the Toolkit thread, chaos ensues.
>> 
>> This commit replaces the collection with a thread-safe  one, more consistently guards against exceptions in individual disposers, and adds exception's stacktraces printing in order to facilitate said exceptions' debugging, which are otherwise hard to pinpoint without code modification. 
>> 
>> Originally, the bug was caught on MacOS running an existing test (`DrawRotatedStringUsingRotatedFont`) that would occasionally crash the VM (probably due to double-free detected by libc that abort()'s in this case). It may take many re-tries to reproduce and this wasn't  observed on Linux. The new test (`test/jdk/sun/java2d/Disposer/TestDisposerRace.java`) displays the problem in a more reliable fashion and fails both on MacOS and Linux without this fix.
>
> Maxim Kartashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made DrawRotatedStringUsingRotatedFont.java headful and dropped extra test

This is the exact new test added by the fix so that shouldn't happen.

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

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


From prr at openjdk.org  Fri Aug 12 21:02:11 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Aug 2022 21:02:11 GMT
Subject: RFR: 8292305: [BACKOUT] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
In-Reply-To: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
References: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
Message-ID: <lqHkz445KHENfuVJiB1SWh6N4TrQSUR-ANtqTbBhqzk=.3ea96fca-93b2-42b6-9b43-428ba7484d7d@github.com>

On Fri, 12 Aug 2022 20:30:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 00decca46a77ea9390081655b069008aacfea525.

Marked as reviewed by prr (Reviewer).

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

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


From dholmes at openjdk.org  Fri Aug 12 21:08:23 2022
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 12 Aug 2022 21:08:23 GMT
Subject: RFR: 8292305: [BACKOUT] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
In-Reply-To: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
References: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
Message-ID: <iXlZILRZkD3GHKWnbhn08PeURp3kPW5aet-TuOE2M-E=.849c18df-9890-4126-904e-2141318e567a@github.com>

On Fri, 12 Aug 2022 20:30:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 00decca46a77ea9390081655b069008aacfea525.

Backout looks accurate

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

Marked as reviewed by dholmes (Reviewer).

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


From dcubed at openjdk.org  Fri Aug 12 21:08:23 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 21:08:23 GMT
Subject: RFR: 8292305: [BACKOUT] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
In-Reply-To: <lqHkz445KHENfuVJiB1SWh6N4TrQSUR-ANtqTbBhqzk=.3ea96fca-93b2-42b6-9b43-428ba7484d7d@github.com>
References: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
 <lqHkz445KHENfuVJiB1SWh6N4TrQSUR-ANtqTbBhqzk=.3ea96fca-93b2-42b6-9b43-428ba7484d7d@github.com>
Message-ID: <hulFeAg-YjzgEPE8i3j3QNV-0yrloA3jdRk65U7Pu7I=.0fb69127-1d5f-4f94-8605-0ea4e5c3e86e@github.com>

On Fri, 12 Aug 2022 21:00:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> This reverts commit 00decca46a77ea9390081655b069008aacfea525.
>
> Marked as reviewed by prr (Reviewer).

@prrace - Thanks for the fast review.

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

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


From dcubed at openjdk.org  Fri Aug 12 21:30:24 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 21:30:24 GMT
Subject: RFR: 8292305: [BACKOUT] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
In-Reply-To: <iXlZILRZkD3GHKWnbhn08PeURp3kPW5aet-TuOE2M-E=.849c18df-9890-4126-904e-2141318e567a@github.com>
References: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
 <iXlZILRZkD3GHKWnbhn08PeURp3kPW5aet-TuOE2M-E=.849c18df-9890-4126-904e-2141318e567a@github.com>
Message-ID: <A0xHLzCMkceLL1ICi0gXvlSuP6lNcMNYIxhwquMGfAE=.95044169-73f4-4818-a701-440e7ac86b62@github.com>

On Fri, 12 Aug 2022 21:04:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This reverts commit 00decca46a77ea9390081655b069008aacfea525.
>
> Backout looks accurate

@dholmes-ora - Thanks for the review.

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

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


From dcubed at openjdk.org  Fri Aug 12 21:35:25 2022
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 Aug 2022 21:35:25 GMT
Subject: Integrated: 8292305: [BACKOUT] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
In-Reply-To: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
References: <ErJOYmNMZQ5MUoMw5cqUQPCIiw-3UMm4mxoTyjLY9dI=.ec1c6d63-e59a-413e-b056-a2693b4c1aff@github.com>
Message-ID: <Rq2U7hgqZvz8WaDol-duF5hTTEfrbuVxsCDBaVPP2lw=.5c5d18b9-9557-404d-a259-247df048da62@github.com>

On Fri, 12 Aug 2022 20:30:11 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> This reverts commit 00decca46a77ea9390081655b069008aacfea525.

This pull request has now been integrated.

Changeset: e70747b4
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e70747b4e9bd9c161b95c88ff0d58609f0b08d42
Stats:     146 lines in 3 files changed: 10 ins; 125 del; 11 mod

8292305: [BACKOUT] JDK-8289208 Test DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS

Reviewed-by: prr, dholmes

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

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


From duke at openjdk.org  Fri Aug 12 23:15:49 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 12 Aug 2022 23:15:49 GMT
Subject: RFR: 8292309 : Fix
 java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test
Message-ID: <uFqQUzkuWOrGXowhXEwVwRN5HjCisrPLGNK-rpaUyUc=.6c97b5ba-e463-45d1-8cb4-e4799148e212@github.com>

1) Fixed Parse Exception by removing yesno
test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno
2) Throw jtreg.SkippedException when printer is not configured on the test host
3) Replaced Sysout & TestDialog with ManualTestFrame, which allows to the user to better decide test results and to take screen shot if test fails.

@shurymury

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

Commit messages:
 - 8292309 : Fix java/awt/PrintJob/ConstrainedPrintingTest/ConstrainedPrintingTest.java test

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

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


From asemenov at openjdk.org  Sat Aug 13 06:00:05 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Sat, 13 Aug 2022 06:00:05 GMT
Subject: Integrated: 8286313 [macos] Voice over reads the boolean value as null
 in the JTable
In-Reply-To: <wKAG5GQn5ANeVTnldjLG9ZUnz4mp0vtvLrK94Ft55HU=.3271c96b-cb54-422a-9759-18b811e44f23@github.com>
References: <wKAG5GQn5ANeVTnldjLG9ZUnz4mp0vtvLrK94Ft55HU=.3271c96b-cb54-422a-9759-18b811e44f23@github.com>
Message-ID: <bOvvzsnvaS4xqpw2WrTbO2X3shNWdNJjzubgExSNDJA=.a0ac6af5-b3f0-42ea-b0e6-bfefee819f29@github.com>

On Mon, 25 Jul 2022 16:24:15 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> I have a Table which is extended from AbstractTableModel with String, integer and Boolean values ( to represent checkbox). When the row is selected Voice over reads the Boolean value as null. 
> 
> @azuev-java @mrserb @prrace please review.

This pull request has now been integrated.

Changeset: 8353a333
Author:    Artem Semenov <asemenov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8353a33350eca859842bc6b92bc9a38a60c11e26
Stats:     8 lines in 1 file changed: 7 ins; 0 del; 1 mod

8286313: [macos] Voice over reads the boolean value as null in the JTable

Reviewed-by: prr, kizune

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

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


From jwaters at openjdk.org  Sat Aug 13 06:17:43 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 13 Aug 2022 06:17:43 GMT
Subject: RFR: 8292314: WINAPI address used as conditional in libsplashscreen
Message-ID: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>

libsplashscreen uses the address of the WINAPI UpdateLayeredWindow in the condition of an if block, which will always evaluate to true since the address is never NULL. It is highly unlikely that this is intentional, and is either a harmless mistake that is ultimately optimized out during compilation at best, or an as of yet uncaught, but severe bug in the implementation that fails to call UpdateLayeredWindow at worst. 

Note: As of now the change simply removes the reference, advice is appreciated if the commit is incorrect and the affected site is actually meant to be a call to UpdateLayeredWindow (as well as whatever parameters are required)

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

Commit messages:
 - First try, remove memory address entirely

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

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


From alanb at openjdk.org  Sat Aug 13 08:00:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 13 Aug 2022 08:00:12 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
Message-ID: <A7GEStVz2A3URH6JAhyM_8oywJfp7r2Eby0PtyfZb7U=.6b166cd1-c816-4a4d-b715-681d76f09e42@github.com>

On Fri, 12 Aug 2022 20:14:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Thread.stop() and ThreadGroup.destroy() are called by sun.awt.AppContext.dispose()
> 
> These should no longer be called. Both are deprecated for removal.
> ThreadGroup.destroy() does nothing. Thread.stop() throws UnsupportedOperationException
> for virtual threads, and is expected to do so for all threads if it is not removed before then.
> 
> This fix stops calling these methods and prints a warning from dispose() to encourage
> callers to move away from AppContext which itself will likely be removed in a future release
> since the Webstart and Plugin scenarios that needed it are no longer supported.
> Although most tests that use AppContext are now irrelevant only one test actually fails
> and is removed  so we are doing the least here and the big job of completely getting rid of
> AppContext is for another day.

Thanks for doing this. The changes look reasonable to me and the warning will help catch any attempts to use it in the JDK.

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

Marked as reviewed by alanb (Reviewer).

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


From duke at openjdk.org  Sat Aug 13 13:42:22 2022
From: duke at openjdk.org (Karl T)
Date: Sat, 13 Aug 2022 13:42:22 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in
 a button.
In-Reply-To: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
Message-ID: <DpEmNC6PPQpx8IwyX-foxuutzz8i0ejANi3t6BxAw9Q=.88d39d33-7655-4075-9d33-ed2e330c17f2@github.com>

On Tue, 2 Aug 2022 10:22:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the letter 'S' in the JButton to be underlined if JButton's text has 'S' in its string.
> This is because [**VK_F4**](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506) keycode is 0x73 (115 in decimal) which happens to be value of lowercase [**'s'** ](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(), the first index of the character (either lowecasr or uppercase) is returned as a mnemonic, which gets underlined.
> 
> Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic which corresponds to lowercase p->z

Changes requested by DevCharly at github.com (no known OpenJDK username).

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

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


From duke at openjdk.org  Sat Aug 13 14:00:12 2022
From: duke at openjdk.org (Karl T)
Date: Sat, 13 Aug 2022 14:00:12 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in
 a button.
In-Reply-To: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
Message-ID: <Xn0ZXc1xhERdGphm4o2agEFtzocckYm1s44GHfkhzxs=.1f757db2-8647-4e55-be54-48349eb1c876@github.com>

On Tue, 2 Aug 2022 10:22:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the letter 'S' in the JButton to be underlined if JButton's text has 'S' in its string.
> This is because [**VK_F4**](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506) keycode is 0x73 (115 in decimal) which happens to be value of lowercase [**'s'** ](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(), the first index of the character (either lowecasr or uppercase) is returned as a mnemonic, which gets underlined.
> 
> Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic which corresponds to lowercase p->z

src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 2089:

> 2087:            return -1;
> 2088:         }
> 2089: 

There are some issues with this implementation IMHO:
- why invoke `KeyEvent.getKeyText(mnemonic)` eleven times? This creates eleven temporary strings. The result is always the same.
- `KeyEvent.getKeyText()` may return localized strings, which would break the fix
- why not simply compare `mnemonic` with ` KeyEvent.VK_F*`?

Following should do the same:
~~~java
if (mnemonic >= KeyEvent.VK_F1 && mnemonic <= KeyEvent.VK_F11) {
    return -1;
}
~~~

But IMO **all lowercase ascii characters** should be excluded because there are more `VK_` keys in this range (e.g. `setMnemonic(VK_NUMPAD1)` would underline the 'a' character, but `Alt+A` does not click the button):

~~~java
if (mnemonic >= 'a' && mnemonic <= 'z') {
    return -1;
}
~~~

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

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


From duke at openjdk.org  Sat Aug 13 15:20:20 2022
From: duke at openjdk.org (Karl T)
Date: Sat, 13 Aug 2022 15:20:20 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v6]
In-Reply-To: <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
Message-ID: <b8MW5SzKzItWZav23rKSmwF-mdm-rMzKMzbBCj293I4=.0805e04a-0320-4437-9271-fa02cb3e8ea8@github.com>

On Thu, 28 Jul 2022 04:07:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
>> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove implNote tag

Hmm, have some concerns with this change.

### Why not allow zero divider size?

The look and feel could use an invisible 6px wide divider that partly overlaps the left and right components.
Then moving divider is still possible, but no divider is visible, which is often used in modern UI.
I actually plan to implement this for [FlatLaf](https://github.com/JFormDesigner/FlatLaf).

Sure, with current L&Fs it is not possible to move divider when dividerSize is zero,
but applications may still control the divider location with `JSplitPane.setDividerLocation()`.
So it is possible that dividerSize zero is used in existing applications.


### Why ignoring negative values?

Wouldn't it better to throw an `IllegalArgumentException` to give the developer some feedback?
Isn't this common practice in Java?
There are several parameter checks in `JSplitPane` and all throw `IllegalArgumentException`.
E.g. `JSplitPane.setResizeWeight(double)`

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

Changes requested by DevCharly at github.com (no known OpenJDK username).

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


From duke at openjdk.org  Sat Aug 13 22:52:38 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Sat, 13 Aug 2022 22:52:38 GMT
Subject: RFR: 8292328 : AccessibleActionsTest.java test instruction for show
 popup on JLabel did not specify shift key
Message-ID: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>

Corrected the test instruction to show the popup menu on JLabel when voice over is enabled .

@shurymury

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

Commit messages:
 - 8292328 : AccessibleActionsTest.java test instruction for show popup on JLabel did not specify shift key

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

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


From iris at openjdk.org  Sun Aug 14 23:55:24 2022
From: iris at openjdk.org (Iris Clark)
Date: Sun, 14 Aug 2022 23:55:24 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
Message-ID: <sMEAV9ju2JItgfmVHWl4uaS-kC-lIjh7lyXsmkEWH28=.d5ffb851-c0a5-48ed-960f-c88ed6e40050@github.com>

On Fri, 12 Aug 2022 20:14:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Thread.stop() and ThreadGroup.destroy() are called by sun.awt.AppContext.dispose()
> 
> These should no longer be called. Both are deprecated for removal.
> ThreadGroup.destroy() does nothing. Thread.stop() throws UnsupportedOperationException
> for virtual threads, and is expected to do so for all threads if it is not removed before then.
> 
> This fix stops calling these methods and prints a warning from dispose() to encourage
> callers to move away from AppContext which itself will likely be removed in a future release
> since the Webstart and Plugin scenarios that needed it are no longer supported.
> Although most tests that use AppContext are now irrelevant only one test actually fails
> and is removed  so we are doing the least here and the big job of completely getting rid of
> AppContext is for another day.

src/java.desktop/share/classes/sun/awt/AppContext.java line 406:

> 404:             Remove all uses of this internal class as soon as possible.
> 405:             There is no replacement.
> 406:             """);

Should some portion of this warning be included in an `@implNote` in this method's JavaDoc?

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

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


From prr at openjdk.org  Mon Aug 15 03:49:55 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 15 Aug 2022 03:49:55 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <sMEAV9ju2JItgfmVHWl4uaS-kC-lIjh7lyXsmkEWH28=.d5ffb851-c0a5-48ed-960f-c88ed6e40050@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
 <sMEAV9ju2JItgfmVHWl4uaS-kC-lIjh7lyXsmkEWH28=.d5ffb851-c0a5-48ed-960f-c88ed6e40050@github.com>
Message-ID: <nTsnNVM9ZGIx1nJLO08fAI1eay4KcQ803Z4hQPC2zvE=.aeae0e6a-b9fb-4846-adf2-0dc2a3e8745f@github.com>

On Sun, 14 Aug 2022 23:53:21 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Thread.stop() and ThreadGroup.destroy() are called by sun.awt.AppContext.dispose()
>> 
>> These should no longer be called. Both are deprecated for removal.
>> ThreadGroup.destroy() does nothing. Thread.stop() throws UnsupportedOperationException
>> for virtual threads, and is expected to do so for all threads if it is not removed before then.
>> 
>> This fix stops calling these methods and prints a warning from dispose() to encourage
>> callers to move away from AppContext which itself will likely be removed in a future release
>> since the Webstart and Plugin scenarios that needed it are no longer supported.
>> Although most tests that use AppContext are now irrelevant only one test actually fails
>> and is removed  so we are doing the least here and the big job of completely getting rid of
>> AppContext is for another day.
>
> src/java.desktop/share/classes/sun/awt/AppContext.java line 406:
> 
>> 404:             Remove all uses of this internal class as soon as possible.
>> 405:             There is no replacement.
>> 406:             """);
> 
> Should some portion of this warning be included in an `@implNote` in this method's JavaDoc?

Since it is internal API I think that unnecessarily generous.
It shouldn't be called anyway.

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

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


From iris at openjdk.org  Mon Aug 15 07:18:32 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 15 Aug 2022 07:18:32 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <nTsnNVM9ZGIx1nJLO08fAI1eay4KcQ803Z4hQPC2zvE=.aeae0e6a-b9fb-4846-adf2-0dc2a3e8745f@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
 <sMEAV9ju2JItgfmVHWl4uaS-kC-lIjh7lyXsmkEWH28=.d5ffb851-c0a5-48ed-960f-c88ed6e40050@github.com>
 <nTsnNVM9ZGIx1nJLO08fAI1eay4KcQ803Z4hQPC2zvE=.aeae0e6a-b9fb-4846-adf2-0dc2a3e8745f@github.com>
Message-ID: <sr2vRSB6sbesFFemD3DZcQ2HYLNRS__I96g4HRDVshc=.76756cef-43a0-4cbf-97fe-eb57b4e6d708@github.com>

On Mon, 15 Aug 2022 03:46:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/awt/AppContext.java line 406:
>> 
>>> 404:             Remove all uses of this internal class as soon as possible.
>>> 405:             There is no replacement.
>>> 406:             """);
>> 
>> Should some portion of this warning be included in an `@implNote` in this method's JavaDoc?
>
> Since it is internal API I think that unnecessarily generous.
> It shouldn't be called anyway.

Sounds reasonable.

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

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


From iris at openjdk.org  Mon Aug 15 07:40:13 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 15 Aug 2022 07:40:13 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
Message-ID: <7iF2-tGt1vtFoU5Y-xCubObFds5TE6sPgVXWaj2DBuU=.89dddf37-bd35-4775-8968-89fa69fdca68@github.com>

On Fri, 12 Aug 2022 20:14:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Thread.stop() and ThreadGroup.destroy() are called by sun.awt.AppContext.dispose()
> 
> These should no longer be called. Both are deprecated for removal.
> ThreadGroup.destroy() does nothing. Thread.stop() throws UnsupportedOperationException
> for virtual threads, and is expected to do so for all threads if it is not removed before then.
> 
> This fix stops calling these methods and prints a warning from dispose() to encourage
> callers to move away from AppContext which itself will likely be removed in a future release
> since the Webstart and Plugin scenarios that needed it are no longer supported.
> Although most tests that use AppContext are now irrelevant only one test actually fails
> and is removed  so we are doing the least here and the big job of completely getting rid of
> AppContext is for another day.

Marked as reviewed by iris (Reviewer).

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

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


From alanb at openjdk.org  Mon Aug 15 08:08:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 08:08:12 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <sr2vRSB6sbesFFemD3DZcQ2HYLNRS__I96g4HRDVshc=.76756cef-43a0-4cbf-97fe-eb57b4e6d708@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
 <sMEAV9ju2JItgfmVHWl4uaS-kC-lIjh7lyXsmkEWH28=.d5ffb851-c0a5-48ed-960f-c88ed6e40050@github.com>
 <nTsnNVM9ZGIx1nJLO08fAI1eay4KcQ803Z4hQPC2zvE=.aeae0e6a-b9fb-4846-adf2-0dc2a3e8745f@github.com>
 <sr2vRSB6sbesFFemD3DZcQ2HYLNRS__I96g4HRDVshc=.76756cef-43a0-4cbf-97fe-eb57b4e6d708@github.com>
Message-ID: <LdNv2oxFvNrPyh9N4Y-Am-PokM7BO9gANSe5tpyW4TE=.ffdaa1a9-0717-4751-9915-8def888ae120@github.com>

On Mon, 15 Aug 2022 07:14:36 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Since it is internal API I think that unnecessarily generous.
>> It shouldn't be called anyway.
>
> Sounds reasonable.

Maybe in time it can be removed, which removes the temptation to use it completely.

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

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


From aturbanov at openjdk.org  Mon Aug 15 08:23:08 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Aug 2022 08:23:08 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
Message-ID: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>

It's a bit shorter and clearer.

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

Commit messages:
 - [PATCH] Use static methods for hashCode/toString primitives

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

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


From duke at openjdk.org  Mon Aug 15 08:23:09 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 15 Aug 2022 08:23:09 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <7O38TdppE3N6L3AVwmwskuzGAMYhslZEk6LNPRPvddk=.ee44fa2d-5624-42a4-a757-7c4b74874699@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Also, it?avoids unnecessary?boxing.

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

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


From prr at openjdk.org  Mon Aug 15 16:45:13 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 15 Aug 2022 16:45:13 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <HLpZp-J-gPnYyisAFC2o37e6OI3JaYya9E8N9bOO8Uw=.92d03070-6dcc-4417-b253-8d30bcfe6186@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Approving (just) the client change

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

Marked as reviewed by prr (Reviewer).

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


From duke at openjdk.org  Mon Aug 15 17:49:32 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 15 Aug 2022 17:49:32 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v2]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <G_4sgYnb4ColuVwKmzpF25mFgXXUOAc5irxP0ERrFso=.777608cf-6862-47e1-8c87-a9a5167ae8a1@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Adds to CSS.java the missing color names.
  
  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 TreeMap called "colorNamed".
    Code is more readable and easy to maintain.
    After tests, HashMap seems slower than TreeMap. Results are available at https://github.com/scientificware/jdk/issues/12#issuecomment-1213978168.
  
  Warning : The Previous JDK CSS Orange Color is different from CSS Color Recommendation.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/bbec633b..8592fe54

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

  Stats: 456 lines in 1 file changed: 156 ins; 298 del; 2 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 dnguyen at openjdk.org  Mon Aug 15 17:54:11 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 15 Aug 2022 17:54:11 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <0G0zF5bYaz6Yu2zRZHmbuYTSqQgWacbkdORWMvN7O-0=.2a330d4d-41b9-4e03-b8e2-76b99e45dc8d@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
 <0G0zF5bYaz6Yu2zRZHmbuYTSqQgWacbkdORWMvN7O-0=.2a330d4d-41b9-4e03-b8e2-76b99e45dc8d@github.com>
Message-ID: <43FdnqPZXOC5g91vHiuRZtXE10o52m0eJj0yAvF98ME=.54da3a9c-c978-4c43-8448-10c0149dc966@github.com>

On Fri, 12 Aug 2022 12:03:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> I am not sure if this is correct approach... Have you seen any macos documentation citing combobox height should not increase even if font size change? That might be problematic for say, accessibility usecase, for slight visually impaired more hearing impaired, where we need to draw them big, right?
> 
> So, assuming it's a issue, I think Since textField height changes with font size, why can't we use the same rectangleForCurrentValue() with which we draw the textField height, for arrowButton height as seen here (https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java#L470)
> 
> I see that we call [AquaCombobBoxButton](https://github.com/openjdk/jdk/blob/master/src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java#L163) with `height`. Are you saying this height, even you change according to font size, is ignored?
> 
> Then it seems this painter.paint() which calls AquaPainter.paintFromSingleCachedImage() which calls MultiResolutionCachedImage to create a MRI maybe is not creating proper MRI image as per the given arrowbutton size. Can you find out why?
> 
> Maybe non-editable combobox can have "single cached image" to have single-sized arrowbutton, but it may not be correct for editable combobox where font size can be changed OR maybe non-editable combobox not changing height for diff. fontsize, also is a result of the above MRI creation issue.

The best documentation I have is the webpage for pull-down buttons here:
[https://developer.apple.com/design/human-interface-guidelines/components/menus-and-actions/pull-down-buttons](url)

There's no text describing the behavior, but the image shows a bracket and lines with arrows on each end to show variable width of a pull-down button. However, for height, the bracket has no arrows, which indicate that the height is fixed.

I'm currently looking at the MRI image issued, but that image combined with the behavior of non-editable comboboxes (even with larger fonts) led me to believe this approach was acceptable.

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

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


From duke at openjdk.org  Mon Aug 15 17:57:12 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 15 Aug 2022 17:57:12 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v2]
In-Reply-To: <KSitJcTkN4kk47Tz_VuokCZTZvr3dF5DyBcRJtnzuKg=.054441cf-0f4b-415e-9f03-f3b12434790f@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <KSitJcTkN4kk47Tz_VuokCZTZvr3dF5DyBcRJtnzuKg=.054441cf-0f4b-415e-9f03-f3b12434790f@github.com>
Message-ID: <d17FKER1KpoXA6X2gSi1kJ9IUunphVVbBzT8yjR5QWw=.682668f0-6300-49cc-b68a-e9ccbc755004@github.com>

On Fri, 12 Aug 2022 09:48:54 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds to CSS.java the missing color names.
>>   
>>   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 TreeMap called "colorNamed".
>>     Code is more readable and easy to maintain.
>>     After tests, HashMap seems slower than TreeMap. Results are available at https://github.com/scientificware/jdk/issues/12#issuecomment-1213978168.
>>   
>>   Warning : The Previous JDK CSS Orange Color is different from CSS Color Recommendation.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1703:
> 
>> 1701:             color = hexToColor("#f5f5f5");
>> 1702:         else if (str.equalsIgnoreCase("Yellowgreen"))
>> 1703:             color = hexToColor("#9acd32");
> 
> This?should probably?use <code>switch([str.toLowerCase][String::toLowerCase]([Locale.ROOT]))</code> instead?of a?linear?search.
> 
> [String::toLowerCase]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/String.html#toLowerCase(java.util.Locale)
> [Locale.ROOT]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/util/Locale.html#ROOT

Hello @ExE-Boss,
A new implementation based on your comments and some performance tests.

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

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


From honkar at openjdk.org  Mon Aug 15 18:24:18 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 15 Aug 2022 18:24:18 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
Message-ID: <HQaYZH4Nc96mk51jF__T8Dzi4iddxHlEXVVPKOShNmo=.fdc1773c-2a02-4df0-8931-86f3b43474e6@github.com>

On Fri, 29 Jul 2022 22:01:44 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added screen insets to account for taskbar position, doc changes
>
> Well .. there surely must be test scenarios where a Frame is required. Perhaps the test moves it, iconifies, needs
> a specific size .. expects focus to move in a certain order between components in the frame .. wants to use
> heavyweight AWT components .. .in some of these I expect the extra instruction part doesn't matter but you only have to find ONE case where it matters .. then there's the fact you'd have to rewrite all the existing tests. And why a JSplitPane, anyway ? Odd choice. 
> 
> I can imagine that it might be interesting to add a new version that works with a JPanel as the container for the test and let a test author decide if they want to use that for future tests.

@prrace PR has been updated with suggested changes and ready for re-review.

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

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


From honkar at openjdk.org  Mon Aug 15 18:43:33 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 15 Aug 2022 18:43:33 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
Message-ID: <X2reQ_V2C6LQPnU_yAqgExkxBKDAHVvfI32Z9XcMvH0=.3bf6bdb2-77ff-4662-b88d-fff7ad8f2a57@github.com>

On Fri, 29 Jul 2022 22:01:44 GMT, Phil Race <prr at openjdk.org> wrote:

> I can imagine that it might be interesting to add a new version that works with a JPanel as the container for the test and let a test author decide if they want to use that for future tests.

As suggested, further changes to PassFailJFrame (creating a new version) will be dealt as a separate issue after evaluating impact of redesigning the framework.

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

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


From rriggs at openjdk.org  Mon Aug 15 19:04:10 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 Aug 2022 19:04:10 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <z6Zu0EJkgkAEEo3SdyI3L9Ugrh0n5u_ePzYzp2GtXHw=.817d4c98-15b5-4ad0-8673-63c362735f5e@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

lgtm

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

Marked as reviewed by rriggs (Reviewer).

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


From duke at openjdk.org  Mon Aug 15 19:43:27 2022
From: duke at openjdk.org (ExE Boss)
Date: Mon, 15 Aug 2022 19:43:27 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v2]
In-Reply-To: <G_4sgYnb4ColuVwKmzpF25mFgXXUOAc5irxP0ERrFso=.777608cf-6862-47e1-8c87-a9a5167ae8a1@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <G_4sgYnb4ColuVwKmzpF25mFgXXUOAc5irxP0ERrFso=.777608cf-6862-47e1-8c87-a9a5167ae8a1@github.com>
Message-ID: <zBJrJiIZSwVdqjQ3cYvB5eJNUkUOvPnmvxl0T_jGXxE=.a23b76e6-89ef-4d0c-85df-02bac3660859@github.com>

On Mon, 15 Aug 2022 17:49:32 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds to CSS.java the missing color names.
>   
>   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 TreeMap called "colorNamed".
>     Code is more readable and easy to maintain.
>     After tests, HashMap seems slower than TreeMap. Results are available at https://github.com/scientificware/jdk/issues/12#issuecomment-1213978168.
>   
>   Warning : The Previous JDK CSS Orange Color is different from CSS Color Recommendation.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1414:

> 1412:     }
> 1413: 
> 1414:     private static TreeMap<String, Color> colorNamed = new TreeMap<String, Color>(

Why?a?`TreeMap` instead?of just?using `Map.ofEntries(?)`?

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

The?latter is?unmodifiable and?its?`table` is?marked as?`@Stable`[^1], which?means that?the?JIT is?allowed to?treat?it as?fully?constant[^2].

[^1]: https://github.com/openjdk/jdk/blob/ea2c82e74f5580f396920f9e561cbec80c03f373/src/java.base/share/classes/java/util/ImmutableCollections.java#L1164-L1170
[^2]: https://github.com/openjdk/jdk/blob/ea2c82e74f5580f396920f9e561cbec80c03f373/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L64-L72

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

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


From duke at openjdk.org  Mon Aug 15 20:29:13 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 15 Aug 2022 20:29:13 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v2]
In-Reply-To: <zBJrJiIZSwVdqjQ3cYvB5eJNUkUOvPnmvxl0T_jGXxE=.a23b76e6-89ef-4d0c-85df-02bac3660859@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <G_4sgYnb4ColuVwKmzpF25mFgXXUOAc5irxP0ERrFso=.777608cf-6862-47e1-8c87-a9a5167ae8a1@github.com>
 <zBJrJiIZSwVdqjQ3cYvB5eJNUkUOvPnmvxl0T_jGXxE=.a23b76e6-89ef-4d0c-85df-02bac3660859@github.com>
Message-ID: <PWMor0b6x52JPWWqgDg8kzJv56FzGO6thZrmmadi6Lk=.a1ed64f2-6de9-4f42-b657-2359c9e6ef03@github.com>

On Mon, 15 Aug 2022 19:39:14 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds to CSS.java the missing color names.
>>   
>>   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 TreeMap called "colorNamed".
>>     Code is more readable and easy to maintain.
>>     After tests, HashMap seems slower than TreeMap. Results are available at https://github.com/scientificware/jdk/issues/12#issuecomment-1213978168.
>>   
>>   Warning : The Previous JDK CSS Orange Color is different from CSS Color Recommendation.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1414:
> 
>> 1412:     }
>> 1413: 
>> 1414:     private static TreeMap<String, Color> colorNamed = new TreeMap<String, Color>(
> 
> Why?a?`TreeMap` instead?of just?using `Map.ofEntries(?)`?
> 
> --------------------------------------------------------------------------------
> 
> The?latter is?unmodifiable and?its?`table` is?marked as?`@Stable`[^1], which?means that?the?JIT is?allowed to?treat?it as?fully?constant[^2].
> 
> [^1]: https://github.com/openjdk/jdk/blob/ea2c82e74f5580f396920f9e561cbec80c03f373/src/java.base/share/classes/java/util/ImmutableCollections.java#L1164-L1170
> [^2]: https://github.com/openjdk/jdk/blob/ea2c82e74f5580f396920f9e561cbec80c03f373/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L64-L72

@ExE-Boss I choosed a TreeMap because it seems it implements the best algorithm to acces algorithm to the values log(n) time.
By maintaining the order of its elements, it's can use compare to accelerate time access.

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

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


From duke at openjdk.org  Mon Aug 15 21:31:17 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 15 Aug 2022 21:31:17 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v2]
In-Reply-To: <zBJrJiIZSwVdqjQ3cYvB5eJNUkUOvPnmvxl0T_jGXxE=.a23b76e6-89ef-4d0c-85df-02bac3660859@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <G_4sgYnb4ColuVwKmzpF25mFgXXUOAc5irxP0ERrFso=.777608cf-6862-47e1-8c87-a9a5167ae8a1@github.com>
 <zBJrJiIZSwVdqjQ3cYvB5eJNUkUOvPnmvxl0T_jGXxE=.a23b76e6-89ef-4d0c-85df-02bac3660859@github.com>
Message-ID: <5ffQlanKzuiFUQFYDHOd42A_3F8JYLgV-VeC3NPyv0o=.bb9c5fb5-dd42-4daf-9d7d-02fcebfd5c9a@github.com>

On Mon, 15 Aug 2022 19:39:14 GMT, ExE Boss <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds to CSS.java the missing color names.
>>   
>>   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 TreeMap called "colorNamed".
>>     Code is more readable and easy to maintain.
>>     After tests, HashMap seems slower than TreeMap. Results are available at https://github.com/scientificware/jdk/issues/12#issuecomment-1213978168.
>>   
>>   Warning : The Previous JDK CSS Orange Color is different from CSS Color Recommendation.
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1414:
> 
>> 1412:     }
>> 1413: 
>> 1414:     private static TreeMap<String, Color> colorNamed = new TreeMap<String, Color>(
> 
> Why?a?`TreeMap` instead?of just?using `Map.ofEntries(?)`?
> 
> --------------------------------------------------------------------------------
> 
> The?latter is?unmodifiable and?its?`table` is?marked as?`@Stable`[^1], which?means that?the?JIT is?allowed to?treat?it as?fully?constant[^2].
> 
> [^1]: https://github.com/openjdk/jdk/blob/ea2c82e74f5580f396920f9e561cbec80c03f373/src/java.base/share/classes/java/util/ImmutableCollections.java#L1164-L1170
> [^2]: https://github.com/openjdk/jdk/blob/ea2c82e74f5580f396920f9e561cbec80c03f373/src/java.base/share/classes/jdk/internal/vm/annotation/Stable.java#L64-L72

@ExE-Boss Map 35% faster than TreeMap.

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

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


From duke at openjdk.org  Mon Aug 15 23:42:35 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 15 Aug 2022 23:42:35 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v3]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <CRos9tNPHgLM26DAEmDaVnN9vf2-dKIXjH01f27U5Ew=.f1ef3e3a-73cf-4f57-b75c-730c52cd0b29@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Adds to CSS.java the missing color names.
  
  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:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/8592fe54..fe428f12

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

  Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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  Tue Aug 16 00:30:29 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 16 Aug 2022 00:30:29 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v3]
In-Reply-To: <CRos9tNPHgLM26DAEmDaVnN9vf2-dKIXjH01f27U5Ew=.f1ef3e3a-73cf-4f57-b75c-730c52cd0b29@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <CRos9tNPHgLM26DAEmDaVnN9vf2-dKIXjH01f27U5Ew=.f1ef3e3a-73cf-4f57-b75c-730c52cd0b29@github.com>
Message-ID: <ZvrG-pv2DdtAw1PiIWHKE4RwHhsb7ZbHylWHKF6pJT8=.4e773b3f-c543-47ad-abf8-84b53712104b@github.com>

On Mon, 15 Aug 2022 23:42:35 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adds to CSS.java the missing color names.
>   
>   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.

Hey there. The current implementation creates a new `Color` object for each invocation of `stringToColor` (with the exception of `""` because we want to keep developers on their toes). Using a `Map` will *not* create new `Color` objects for each invocation, which may explain why your results show `Map` as the most performant. This is *technically* a change in behavior, and *technically* not wanted.

To get around this, you can do `new Color(c.getRed(), c.getGreen(), c.getBlue())` from the map, or--what I would prefer--to use an enhanced switch statement to create the colors.

One thing I'd request is to have `stringToColor` return in the branches, rather than setting the placeholder `Color color;` object. Things like this irk me. As in (using the map):

static Color stringToColor(String str) {
        if (str == null) {
            return null;
        } else if (str.length() == 0) {
            return Color.black;
        } else if (str.startsWith("rgb(")) {
            return parseRGB(str);
        } else if (str.startsWith("rgba(")) {
            return parseRGBA(str);
        } else if (str.charAt(0) == '#') {
            return hexToColor(str);
        } else if (colorNamed.containsKey(str.toLowerCase(Locale.ROOT))) {
            return colorNamed.get(str.toLowerCase(Locale.ROOT));
        } else {
            return hexToColor(str);
        }
    }


In general, good PR. I'd be interested to know the perf results when the behavior is unchanged, and if the enhanced switch would win out.

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

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


From duke at openjdk.org  Tue Aug 16 01:02:11 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 16 Aug 2022 01:02:11 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v3]
In-Reply-To: <ZvrG-pv2DdtAw1PiIWHKE4RwHhsb7ZbHylWHKF6pJT8=.4e773b3f-c543-47ad-abf8-84b53712104b@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <CRos9tNPHgLM26DAEmDaVnN9vf2-dKIXjH01f27U5Ew=.f1ef3e3a-73cf-4f57-b75c-730c52cd0b29@github.com>
 <ZvrG-pv2DdtAw1PiIWHKE4RwHhsb7ZbHylWHKF6pJT8=.4e773b3f-c543-47ad-abf8-84b53712104b@github.com>
Message-ID: <gyAiP4TuA8lzgY4hgbiw3MWNoCsZxtqC-i3Zt88oQMI=.35c0a2d8-db4a-4ad5-909f-2c8bbbfa2a74@github.com>

On Tue, 16 Aug 2022 00:26:47 GMT, SWinxy <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds to CSS.java the missing color names.
>>   
>>   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.
>
> Hey there. The current implementation creates a new `Color` object for each invocation of `stringToColor` (with the exception of `""` because we want to keep developers on their toes). Using a `Map` will *not* create new `Color` objects for each invocation, which may explain why your results show `Map` as the most performant. This is *technically* a change in behavior, and *technically* not wanted.
> 
> To get around this, you can do `new Color(c.getRed(), c.getGreen(), c.getBlue())` from the map, or--what I would prefer--to use an enhanced switch statement to create the colors.
> 
> One thing I'd request is to have `stringToColor` return in the branches, rather than setting the placeholder `Color color;` object. Things like this irk me. As in (using the map):
> 
> static Color stringToColor(String str) {
>         if (str == null) {
>             return null;
>         } else if (str.length() == 0) {
>             return Color.black;
>         } else if (str.startsWith("rgb(")) {
>             return parseRGB(str);
>         } else if (str.startsWith("rgba(")) {
>             return parseRGBA(str);
>         } else if (str.charAt(0) == '#') {
>             return hexToColor(str);
>         } else if (colorNamed.containsKey(str.toLowerCase(Locale.ROOT))) {
>             return colorNamed.get(str.toLowerCase(Locale.ROOT));
>         } else {
>             return hexToColor(str);
>         }
>     }
> 
> 
> In general, good PR. I'd be interested to know the perf results when the behavior is unchanged, and if the enhanced switch would win out.

@SWinxy Thanks for comments. After reading them, I realize the Big Mistake !
I Shouldn't create a new object but rather return an existing one.

That was in my intention. All the code is already available [here](https://github.com/scientificware/jdk/issues/12), I wrote it because I expected to move this logic to Color.java.

All color declarations are ready.

The Map will be something like : 


static TreeMap<String, Color> colorNamed = new TreeMap<String, Color>(
        Map.ofEntries(
            Map.entry("aliceblue", ALICE_BLUE),
            ...
            Map.entry("yellowgreen", YELLOW_GREEN)
        );            

Do you validate this approach ?

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

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


From duke at openjdk.org  Tue Aug 16 02:14:31 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 16 Aug 2022 02:14:31 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v3]
In-Reply-To: <ZvrG-pv2DdtAw1PiIWHKE4RwHhsb7ZbHylWHKF6pJT8=.4e773b3f-c543-47ad-abf8-84b53712104b@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <CRos9tNPHgLM26DAEmDaVnN9vf2-dKIXjH01f27U5Ew=.f1ef3e3a-73cf-4f57-b75c-730c52cd0b29@github.com>
 <ZvrG-pv2DdtAw1PiIWHKE4RwHhsb7ZbHylWHKF6pJT8=.4e773b3f-c543-47ad-abf8-84b53712104b@github.com>
Message-ID: <PlsRzLQkTvp6xF_CbhW7nyd6K8Ct2QL6Dpod6hb0HWA=.f7fc97ae-a961-4a82-8b94-7cbae75c1116@github.com>

On Tue, 16 Aug 2022 00:26:47 GMT, SWinxy <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adds to CSS.java the missing color names.
>>   
>>   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.
>
> Hey there. The current implementation creates a new `Color` object for each invocation of `stringToColor` (with the exception of `""` because we want to keep developers on their toes). Using a `Map` will *not* create new `Color` objects for each invocation, which may explain why your results show `Map` as the most performant. This is *technically* a change in behavior, and *technically* not wanted.
> 
> To get around this, you can do `new Color(c.getRed(), c.getGreen(), c.getBlue())` from the map, or--what I would prefer--to use an enhanced switch statement to create the colors.
> 
> One thing I'd request is to have `stringToColor` return in the branches, rather than setting the placeholder `Color color;` object. Things like this irk me. As in (using the map):
> 
> static Color stringToColor(String str) {
>         if (str == null) {
>             return null;
>         } else if (str.length() == 0) {
>             return Color.black;
>         } else if (str.startsWith("rgb(")) {
>             return parseRGB(str);
>         } else if (str.startsWith("rgba(")) {
>             return parseRGBA(str);
>         } else if (str.charAt(0) == '#') {
>             return hexToColor(str);
>         } else if (colorNamed.containsKey(str.toLowerCase(Locale.ROOT))) {
>             return colorNamed.get(str.toLowerCase(Locale.ROOT));
>         } else {
>             return hexToColor(str);
>         }
>     }
> 
> 
> In general, good PR. I'd be interested to know the perf results when the behavior is unchanged, and if the enhanced switch would win out.

@SWinxy
> I'd be interested to know the perf results when the behavior is unchanged, and if the enhanced switch would win out.
The results are also in my repository, the current implementation is
- five times slower than the worst of other implementations
- and nine times slower than the switch case implementation.

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

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


From tr at openjdk.org  Tue Aug 16 05:57:20 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 16 Aug 2022 05:57:20 GMT
Subject: Integrated: 6521141: DebugGraphics NPE @ setFont();
In-Reply-To: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
References: <ZZRevtg8dFUm0z4At_DTQlUeOhWTDYWS2gXD0oNfYSw=.73c1ab1a-1455-4d0e-8eb8-e627be0b8a4d@github.com>
Message-ID: <0HxlkGWxQiSVpcS00gRsvoH-P1KJ5Xt1FYpYooUNMf8=.3478f948-18e2-4e25-aea4-995eedb47063@github.com>

On Thu, 28 Jul 2022 11:47:03 GMT, Tejesh R <tr at openjdk.org> wrote:

> `DebugGraphics` class has a Graphics instance which is been used in slowed down drawing. The `graphics` object is not initialized anywhere inside the class, where it is expected to set explicitly by the user. When the user doesn't set it and try to use the any mehtods like `drawing/setFont`, NPE is raised which is expected. The scenario is taken care by checking if the `graphics` object is null before using it inside the class, thus eliminating the NPE case.

This pull request has now been integrated.

Changeset: 21f4eb22
Author:    Tejesh R <tr at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21f4eb2233a95be44a5db59b7791cd952ddbd56e
Stats:     64 lines in 2 files changed: 64 ins; 0 del; 0 mod

6521141: DebugGraphics NPE @ setFont();

Reviewed-by: prr

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

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


From mkartashev at openjdk.org  Tue Aug 16 08:36:31 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Tue, 16 Aug 2022 08:36:31 GMT
Subject: RFR: 8292304: [REDO] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
Message-ID: <hoWXjz5E3xFvx9_1GiiCpl5HM4oyWFguc53_I7B8oRA=.2db225d0-0d6c-484c-8804-c73e4c31f349@github.com>

See also the [original pull request](https://github.com/openjdk/jdk/pull/9362) where the change is explained and discussed in details.

Compared to the original version of this fix I
* changed the error reporting from `printStackTrace()` to `System.out.println()` as per @prrace request,
* fixed the test to use `AtomicInteger` for the counter of disposer records as `+=` and `--` operations on a `volatile int` do not guarantee value's integrity, which caused the test to often fail.

`test/jdk/sun/java2d/Disposer/TestDisposerRace.java` now passes successfully on MacOS and Linux.

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

Commit messages:
 - 8292304: [REDO] JDK-8289208 Test DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS

Changes: https://git.openjdk.org/jdk/pull/9890/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9890&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292304
  Stats: 141 lines in 3 files changed: 122 ins; 5 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9890.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9890/head:pull/9890

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


From duke at openjdk.org  Tue Aug 16 17:15:41 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 16 Aug 2022 17:15:41 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v4]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <SUsfPX4_pgphb7EK2CcSob2NdZ_ZJZMnCXO2AX3TVGM=.f73b5390-4d96-4812-b5bf-5b2673b6cc3c@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/fe428f12..852861dc

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

  Stats: 55 lines in 1 file changed: 55 ins; 0 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  Tue Aug 16 17:20:18 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 16 Aug 2022 17:20:18 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v5]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <vF4CzoUpQ98OJWzR_sYJb9A_ok1SawSUhnedbH9ABWw=.d2f311b6-1aa1-407d-8e0a-581f743df4cc@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Rename test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS.java to test/jdk/javax/swing/text/html/CSS/JDK8292276MissingColorNamesInCSS/JDK8292276MissingColorNamesInCSS.java
  
  Move the test case in its repository.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/852861dc..c75d46e6

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

  Stats: 0 lines in 1 file changed: 0 ins; 0 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 dnguyen at openjdk.org  Tue Aug 16 17:30:32 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 16 Aug 2022 17:30:32 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v6]
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <9_BjKy-Zu9Q4YJ1BfLgvVFPAaHeTw3nv6i8SH_XzP4o=.1f4e951d-58eb-4b29-b15f-13ab54cfa2a1@github.com>

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

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

  Modified test for native sizing.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9473/files
  - new: https://git.openjdk.org/jdk/pull/9473/files/78db9fbe..fe0d2f81

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

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

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


From dnguyen at openjdk.org  Tue Aug 16 17:32:23 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 16 Aug 2022 17:32:23 GMT
Subject: RFR: 7189422: [macosx] Submenu's arrow have a wrong position
In-Reply-To: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
References: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
Message-ID: <9NYPgX-R52MZIzwT_Z3anw6yONBfCW8X2GG4bWXTXiE=.088626a9-a048-4835-9ccb-22f2c286dbab@github.com>

On Fri, 5 Aug 2022 08:58:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is Arrow in submenu with empty title have a wrong position in Aqua L&F as can be seen
> 
> <img width="94" alt="image" src="https://user-images.githubusercontent.com/43534309/183023538-de8e51b4-31e6-45d7-b2bd-35da5e29c1e8.png">
> 
> 
> which is because the text being null/empty, `labelR` rectangle width/height is 0 so arrowIcon y coordinate becomes -ve as per the calculation in layoutMenuItem(). Although it seems logical to me to not show the arrow if submenu text is null, but
> whereas for other L&F, it is shown as this 
> for Metal
> <img width="83" alt="image" src="https://user-images.githubusercontent.com/43534309/183022436-d9e8ebf1-98de-4cf6-bf43-3713357846e5.png">
> 
> for Nimbus
> <img width="77" alt="image" src="https://user-images.githubusercontent.com/43534309/183022730-35d170b2-71c6-4231-9a03-880107dc49c6.png">
> 
> so the fix is made in Aqua L&F to show as other L&F as
> <img width="92" alt="image" src="https://user-images.githubusercontent.com/43534309/183023030-7356086d-957c-4e0d-bd52-bdf3493a96b0.png">

Applied your changes and ran the test. The fix works as described.

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

Marked as reviewed by dnguyen (Author).

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


From jjg at openjdk.org  Tue Aug 16 17:37:29 2022
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 16 Aug 2022 17:37:29 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <mY_ICKm2YiPrsuAYYYJbJCpX3dSMDD3WpUxp5KnR_Mg=.8d1bce53-7139-4986-be60-a9445fe12745@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

`jdk.compiler` and `jdk.javadoc` changes look OK

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

Marked as reviewed by jjg (Reviewer).

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


From naoto at openjdk.org  Tue Aug 16 17:48:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Aug 2022 17:48:39 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <xzJJkvV1oqcon8KDl5Z8u4KJlP6Udn77VaNko0wHbxA=.83d42205-be39-43b0-be36-17fb59192479@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Those `.properties` bundle changes look good.

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

Marked as reviewed by naoto (Reviewer).

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


From prr at openjdk.org  Tue Aug 16 18:06:13 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 16 Aug 2022 18:06:13 GMT
Subject: RFR: 8292314: WINAPI address used as conditional in
 libsplashscreen
In-Reply-To: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
References: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
Message-ID: <uQPAaGYkqDCr8rdxM62BFYlPPq3zqFfZyeMoeAgUB8w=.305529f0-af24-4bc7-8437-5a04a93fbab7@github.com>

On Sat, 13 Aug 2022 06:09:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> libsplashscreen uses the address of the WINAPI UpdateLayeredWindow in the condition of an if block, which will always evaluate to true since the address is never NULL. It is highly unlikely that this is intentional, and is either a harmless mistake that is ultimately optimized out during compilation at best, or an as of yet uncaught, but severe bug in the implementation that fails to call UpdateLayeredWindow at worst. 
> 
> Note: As of now the change simply removes the reference, advice is appreciated if the commit is incorrect and the affected site is actually meant to be a call to UpdateLayeredWindow (as well as whatever parameters are required)

It wasn't a mistake. It was deliberate. That function used to be looked up at runtime.
However it was obsoleted by http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/75755e92430c
So it is safe to remove it now.

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

Marked as reviewed by prr (Reviewer).

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


From azvegint at openjdk.org  Tue Aug 16 18:12:28 2022
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 16 Aug 2022 18:12:28 GMT
Subject: RFR: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
Message-ID: <MI2gzUz9-vjX6zHlib0Eu5NC-6OmR_DpvQniiCTRCRI=.cb97a104-7b42-4fc4-a943-ce43d7e4f695@github.com>

On Fri, 12 Aug 2022 20:14:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Thread.stop() and ThreadGroup.destroy() are called by sun.awt.AppContext.dispose()
> 
> These should no longer be called. Both are deprecated for removal.
> ThreadGroup.destroy() does nothing. Thread.stop() throws UnsupportedOperationException
> for virtual threads, and is expected to do so for all threads if it is not removed before then.
> 
> This fix stops calling these methods and prints a warning from dispose() to encourage
> callers to move away from AppContext which itself will likely be removed in a future release
> since the Webstart and Plugin scenarios that needed it are no longer supported.
> Although most tests that use AppContext are now irrelevant only one test actually fails
> and is removed  so we are doing the least here and the big job of completely getting rid of
> AppContext is for another day.

Marked as reviewed by azvegint (Reviewer).

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

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


From iris at openjdk.org  Tue Aug 16 18:26:17 2022
From: iris at openjdk.org (Iris Clark)
Date: Tue, 16 Aug 2022 18:26:17 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <RHDfWJb7R7zhWFU08KXiXDqIvgJTkdn3fXSazBi58HE=.dfd63f3c-0ae8-45b4-a43d-5d48a17c6337@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Marked as reviewed by iris (Reviewer).

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

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


From aivanov at openjdk.org  Tue Aug 16 19:23:42 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 16 Aug 2022 19:23:42 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v19]
In-Reply-To: <U8BQDx3UEY2GYEoYklOJYqxtt39_2dFex6GWYQfMwaY=.3bf4de53-66df-48cd-afb2-6b82625704bc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <U8BQDx3UEY2GYEoYklOJYqxtt39_2dFex6GWYQfMwaY=.3bf4de53-66df-48cd-afb2-6b82625704bc@github.com>
Message-ID: <udiO0CFi8HsLECowfDIH715tCSjhUeVucsQ8-V6aLQg=.112f66c0-037d-4fac-bc6d-b61f59300ccc@github.com>

On Fri, 12 Aug 2022 20:22:30 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per review comments

Marked as reviewed by aivanov (Reviewer).

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

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


From prr at openjdk.org  Tue Aug 16 19:23:42 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 16 Aug 2022 19:23:42 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v19]
In-Reply-To: <U8BQDx3UEY2GYEoYklOJYqxtt39_2dFex6GWYQfMwaY=.3bf4de53-66df-48cd-afb2-6b82625704bc@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <U8BQDx3UEY2GYEoYklOJYqxtt39_2dFex6GWYQfMwaY=.3bf4de53-66df-48cd-afb2-6b82625704bc@github.com>
Message-ID: <aqwO3NDPEc9wq5ogT8RSiNJ4TxIwb_l119RVXmNdDRg=.75dc48cd-2363-457d-8f35-2a042cac9164@github.com>

On Fri, 12 Aug 2022 20:22:30 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per review comments

Changes requested by prr (Reviewer).

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

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


From prr at openjdk.org  Tue Aug 16 19:23:43 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 16 Aug 2022 19:23:43 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <8lHo1rsec5xI6GN2valYvFnThPcH0cVvTIlTY0UhbuM=.14b550ad-827e-4468-8d1e-1900e05cd3f2@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
 <MiKWVJP-R9qTb7W9Lg3aM4qZIPjrSCJOfpshG-4MoYE=.293f327e-65e9-402e-9341-159fef76704f@github.com>
 <8lHo1rsec5xI6GN2valYvFnThPcH0cVvTIlTY0UhbuM=.14b550ad-827e-4468-8d1e-1900e05cd3f2@github.com>
Message-ID: <IG9rT5c3xbgXUnNkmtLVPfGKitHVdaxuL49Xfjus8pc=.aa4359a0-1277-4759-a15d-7f76aa4cf169@github.com>

On Thu, 11 Aug 2022 19:36:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> It's reachable when `listViewWindowsStyle` is `false`, which seems to be the case in all the Look-and-Feels but Windows one.
> 
> Yet it looks confusing.

We have
                if (listViewWindowsStyle) {
                     ..
                 } else if (len < 1024L) {
                     ...
                 } else if (len < 100L) {

So if listViewWindowsStyle is false then we get to < 1024 case and if there len is (say) 20
we enter that, so as far as I can see we can never reach the < 100 case.

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

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


From duke at openjdk.org  Tue Aug 16 21:37:30 2022
From: duke at openjdk.org (ScientificWare)
Date: Tue, 16 Aug 2022 21:37:30 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v6]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

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

  Removes whitespace.
  
  Remove a whitespace at the end of the file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/c75d46e6..da6e34f4

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

  Stats: 0 lines in 0 files changed: 0 ins; 0 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 prr at openjdk.org  Tue Aug 16 22:57:16 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 16 Aug 2022 22:57:16 GMT
Subject: Integrated: 8289616: Drop use of Thread.stop in AppContext
In-Reply-To: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
References: <1Afss0jW5i5qyerwYcYYt8q1W4q7Vj2IWTvBi-K4TTE=.8bdb3c8e-d789-4e2f-ab15-7ce2227d31a5@github.com>
Message-ID: <EyYMVgalo1_OUVISVXL2SjUPTs19XhoEq5MJC4wXVOE=.260b1bfc-2698-4cc7-b8b4-72038b898bd5@github.com>

On Fri, 12 Aug 2022 20:14:27 GMT, Phil Race <prr at openjdk.org> wrote:

> Thread.stop() and ThreadGroup.destroy() are called by sun.awt.AppContext.dispose()
> 
> These should no longer be called. Both are deprecated for removal.
> ThreadGroup.destroy() does nothing. Thread.stop() throws UnsupportedOperationException
> for virtual threads, and is expected to do so for all threads if it is not removed before then.
> 
> This fix stops calling these methods and prints a warning from dispose() to encourage
> callers to move away from AppContext which itself will likely be removed in a future release
> since the Webstart and Plugin scenarios that needed it are no longer supported.
> Although most tests that use AppContext are now irrelevant only one test actually fails
> and is removed  so we are doing the least here and the big job of completely getting rid of
> AppContext is for another day.

This pull request has now been integrated.

Changeset: 01b87ba8
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01b87ba8e2c48ad29c1f4771973ebbe938967448
Stats:     118 lines in 2 files changed: 7 ins; 111 del; 0 mod

8289616: Drop use of Thread.stop in AppContext

Reviewed-by: alanb, iris, azvegint

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

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


From duke at openjdk.org  Tue Aug 16 23:19:12 2022
From: duke at openjdk.org (SWinxy)
Date: Tue, 16 Aug 2022 23:19:12 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v6]
In-Reply-To: <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
Message-ID: <JTiG4xb_kwM-gHYfR7dP_c8H3tjXcuVeY3C8I5f0wzA=.b7afc4b0-4b2e-4ab0-b991-2d954b81b290@github.com>

On Tue, 16 Aug 2022 21:37:30 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes whitespace.
>   
>   Remove a whitespace at the end of the file

That's a bit sus for the enhanced switch statement to be significantly slower (7.5x more time than the map). Your methodology still shows that you aren't creating new objects for each invocation and returning the same objects each time. Is that accurate to your performance table?

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

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


From honkar at openjdk.org  Wed Aug 17 00:17:25 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 17 Aug 2022 00:17:25 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v6]
In-Reply-To: <9_BjKy-Zu9Q4YJ1BfLgvVFPAaHeTw3nv6i8SH_XzP4o=.1f4e951d-58eb-4b29-b15f-13ab54cfa2a1@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <9_BjKy-Zu9Q4YJ1BfLgvVFPAaHeTw3nv6i8SH_XzP4o=.1f4e951d-58eb-4b29-b15f-13ab54cfa2a1@github.com>
Message-ID: <Ufr-ac-3TAbM6XCiZHyZcgo1HkU--QV7M3tgoaMuRUw=.ebc49b65-1b27-4bf9-8e39-458fd49e2d86@github.com>

On Tue, 16 Aug 2022 17:30:32 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified test for native sizing.

Tested on Mac 12.3. The editable combobox looks quite close to the non editable one. 

> Ideally, the textfield also should have a focus border around it similar to button, so it will look uniform, so instead of removing border from button, we can try to draw focus border around textfield.

Just a thought: As @prsadhuk suggested earlier, carrying forward the focus ring style & thickness of the button over to the textfield might help in giving the editable combobox (textfield + button) a unified look when it has focus.

![image](https://user-images.githubusercontent.com/95945681/185005697-be9eb779-15fb-4792-95df-77c3917a80cc.png)

![image](https://user-images.githubusercontent.com/95945681/185005741-1bb845c2-4aad-41b0-bf0e-1e965dc7c9c2.png)

Minor changes:
Copyright year for AquaComboBoxUI needs to be updated
Adding MacOS test - either in the instructionText or summary of the test.

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

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


From psadhukhan at openjdk.org  Wed Aug 17 03:25:33 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 17 Aug 2022 03:25:33 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in
 a button. [v2]
In-Reply-To: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
Message-ID: <THp-bCWx--fD6Nq-UD2dQIA8_vJTsyrxN44bJd21IeA=.ae85edb2-d0ef-4690-ba2e-825b4d1f1608@github.com>

> It is seen that using VK_F4 in JButton's setMnemonic(int i), causes the letter 'S' in the JButton to be underlined if JButton's text has 'S' in its string.
> This is because [**VK_F4**](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java#L506) keycode is 0x73 (115 in decimal) which happens to be value of lowercase [**'s'** ](https://www.cs.cmu.edu/~pattis/15-1XX/common/handouts/ascii.html) so as per the logic implemented in SwingUtilities.findDisplayedMnemonicIndex(), the first index of the character (either lowecasr or uppercase) is returned as a mnemonic, which gets underlined.
> 
> Fix is made to ignore Action Keys from VK_F1->VK_F11 as displayed mnemonic which corresponds to lowercase p->z

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

  Modify check for lowercase character

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9712/files
  - new: https://git.openjdk.org/jdk/pull/9712/files/9942d8bb..3f4ae080

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

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

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


From psadhukhan at openjdk.org  Wed Aug 17 03:25:33 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 17 Aug 2022 03:25:33 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in
 a button. [v2]
In-Reply-To: <Xn0ZXc1xhERdGphm4o2agEFtzocckYm1s44GHfkhzxs=.1f757db2-8647-4e55-be54-48349eb1c876@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
 <Xn0ZXc1xhERdGphm4o2agEFtzocckYm1s44GHfkhzxs=.1f757db2-8647-4e55-be54-48349eb1c876@github.com>
Message-ID: <SJPUxlkG2YLybePpodjcWqaN-vPI1rQ2sv6jIxC-2J4=.6f3432d1-f2c4-48bb-9484-e258eda14281@github.com>

On Sat, 13 Aug 2022 13:39:08 GMT, Karl T <duke at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modify check for lowercase character
>
> src/java.desktop/share/classes/javax/swing/SwingUtilities.java line 2089:
> 
>> 2087:            return -1;
>> 2088:         }
>> 2089: 
> 
> There are some issues with this implementation IMHO:
> - why invoke `KeyEvent.getKeyText(mnemonic)` eleven times? This creates eleven temporary strings. The result is always the same.
> - `KeyEvent.getKeyText()` may return localized strings, which would break the fix
> - why not simply compare `mnemonic` with ` KeyEvent.VK_F*`?
> 
> Following should do the same:
> ~~~java
> if (mnemonic >= KeyEvent.VK_F1 && mnemonic <= KeyEvent.VK_F11) {
>     return -1;
> }
> ~~~
> 
> But IMO **all lowercase ascii characters** should be excluded because there are more `VK_` keys in this range (e.g. `setMnemonic(VK_NUMPAD1)` would underline the 'a' character, but `Alt+A` does not click the button):
> 
> ~~~java
> if (mnemonic >= 'a' && mnemonic <= 'z') {
>     return -1;
> }
> ~~~

Yes, calling KeyEvent.getKeyText(mnemonic) so many times is a mistake, which could have been done once.

I was also sceptical about checking for 'a' to 'z' as spec of method says "This method is only designed to handle character values which fall between 'a' and 'z' or 'A' and 'Z'." so 'a', 'z' are valid characters but this method is for displaying Mnemonic index which is not affected and it prevents the action keys underlining lowercase characters.

Thanks for your suggestion which is incorporated.

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

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


From jwaters at openjdk.org  Wed Aug 17 03:51:26 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 17 Aug 2022 03:51:26 GMT
Subject: RFR: 8292314: WINAPI address used as conditional in
 libsplashscreen
In-Reply-To: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
References: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
Message-ID: <mHn6g_Ts8DBzebeaWyxU7150PQDx5iv80C9qxlYn1Vw=.4a384fc4-13e9-459e-926b-2a8469b0c490@github.com>

On Sat, 13 Aug 2022 06:09:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> libsplashscreen uses the address of the WINAPI UpdateLayeredWindow in the condition of an if block, which will always evaluate to true since the address is never NULL. It is highly unlikely that this is intentional, and is either a harmless mistake that is ultimately optimized out during compilation at best, or an as of yet uncaught, but severe bug in the implementation that fails to call UpdateLayeredWindow at worst. 
> 
> Note: As of now the change simply removes the reference, advice is appreciated if the commit is incorrect and the affected site is actually meant to be a call to UpdateLayeredWindow (as well as whatever parameters are required)

I see, will change the issue to reflect that before integrating

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

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


From duke at openjdk.org  Wed Aug 17 04:17:27 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 04:17:27 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v17]
In-Reply-To: <IG9rT5c3xbgXUnNkmtLVPfGKitHVdaxuL49Xfjus8pc=.aa4359a0-1277-4759-a15d-7f76aa4cf169@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <d9OKzmsigxYWqvUvG7BXXJGy1IIE5Du0srcZQvSHY94=.9abfd2c4-7af5-4dbb-8bef-c9c8b03e69bc@github.com>
 <MiKWVJP-R9qTb7W9Lg3aM4qZIPjrSCJOfpshG-4MoYE=.293f327e-65e9-402e-9341-159fef76704f@github.com>
 <8lHo1rsec5xI6GN2valYvFnThPcH0cVvTIlTY0UhbuM=.14b550ad-827e-4468-8d1e-1900e05cd3f2@github.com>
 <IG9rT5c3xbgXUnNkmtLVPfGKitHVdaxuL49Xfjus8pc=.aa4359a0-1277-4759-a15d-7f76aa4cf169@github.com>
Message-ID: <dkqlHST9WyBRJe1_8JASydKTkAQUo265PNBtdULYhr4=.0b7f149b-f9bf-4701-be08-175c802241c2@github.com>

On Tue, 16 Aug 2022 19:21:12 GMT, Phil Race <prr at openjdk.org> wrote:

>> It's reachable when `listViewWindowsStyle` is `false`, which seems to be the case in all the Look-and-Feels but Windows one.
>> 
>> Yet it looks confusing.
>
>> It's reachable when `listViewWindowsStyle` is `false`, which seems to be the case in all the Look-and-Feels but Windows one.
>> 
>> Yet it looks confusing.
> 
> We have
>                 if (listViewWindowsStyle) {
>                      ..
>                  } else if (len < 1024L) {
>                      ...
>                  } else if (len < 100L) {
> 
> So if listViewWindowsStyle is false then we get to < 1024 case and if there len is (say) 20
> we enter that, so as far as I can see we can never reach the < 100 case.

} else if (len < 1024L) {
...
} has been removed. 
So if listViewWindowStyle is false then the next else if condition will be executed i.e. <100L case.

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

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


From duke at openjdk.org  Wed Aug 17 04:29:22 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 04:29:22 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <Mob16bWMjoymF5RoSMaTCfGWk6qc4gdKCzNX6U1enr0=.a33baf4e-b0ad-44ac-95fa-b283026f7850@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
 <Mob16bWMjoymF5RoSMaTCfGWk6qc4gdKCzNX6U1enr0=.a33baf4e-b0ad-44ac-95fa-b283026f7850@github.com>
Message-ID: <37PLBrSt3h8f3b0vxFRl4HwHpKwCkWaymy-sHGMMgic=.2d56b930-8377-45e1-8264-a83a55789cd5@github.com>

On Wed, 10 Aug 2022 19:30:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated as per  review comments
>
> To have all files 1->1000 bytes be 1.0kB and  yet 1,100 -> 1,200 bytes be 1.1kB does seem anomalous
> from a precision perspective, since the major order of magnitude would seem to be more important to describe.
> 
> Since we already aren't going to say "bytes" for those small files, then just getting that precision with
>  the decimal point seems better - as well as being consistent !

@prrace 

} else if (len < 1024L) {
...
} has been removed in previous commit. 
So if listViewWindowsStyle is false then the next else if will be executed i.e. <100L.

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

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


From tr at openjdk.org  Wed Aug 17 06:16:00 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Aug 2022 06:16:00 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length
Message-ID: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>

The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.

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

Commit messages:
 - Removed white spaces
 - Fix : negative length check added and corresponding test added
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - Merge remote-tracking branch 'upstream/master'
 - ... and 3 more: https://git.openjdk.org/jdk/compare/77398430...2faa3400

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

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


From duke at openjdk.org  Wed Aug 17 06:41:46 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 17 Aug 2022 06:41:46 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v6]
In-Reply-To: <JTiG4xb_kwM-gHYfR7dP_c8H3tjXcuVeY3C8I5f0wzA=.b7afc4b0-4b2e-4ab0-b991-2d954b81b290@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
 <JTiG4xb_kwM-gHYfR7dP_c8H3tjXcuVeY3C8I5f0wzA=.b7afc4b0-4b2e-4ab0-b991-2d954b81b290@github.com>
Message-ID: <k7BDUXspNENTA4AHysiaIQwnEZBaagz9P5BoAK3039w=.e5659f8a-46de-4519-abdc-0ab866650680@github.com>

On Tue, 16 Aug 2022 23:15:38 GMT, SWinxy <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes whitespace.
>>   
>>   Remove a whitespace at the end of the file
>
> That's a bit sus for the enhanced switch statement to be significantly slower (7.5x more time than the map). Your methodology still shows that you aren't creating new objects for each invocation and returning the same objects each time. Is that accurate to your performance table?

Yes @SWinxy, you're right. Map and TreeMap implementations return the same object. Therefore comparisons with the current implemention or switch case solution are not relevant.  I going to add a test result with Map + your workaround.

Presently, the switch case solution is the best in respect of the current behaviors you want to preserve.

I integrated all your comments but yesterday, I was busy with the test case and other propositions that could content you. I take time to found the best solution because there are other places in swing html package where such optimisation would be interresting, especially in view factories.

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

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


From psadhukhan at openjdk.org  Wed Aug 17 06:44:31 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 17 Aug 2022 06:44:31 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length
In-Reply-To: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
Message-ID: <x-2Do3arBpcp-_wC8ISn5dS6EDyYtpIhrCkT4zKwRJc=.bf0917dd-c670-4821-878b-a4691a9cb54d@github.com>

On Thu, 11 Aug 2022 05:21:48 GMT, Tejesh R <tr at openjdk.org> wrote:

> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.

test/jdk/javax/swing/JTextPane/DefaultStyledDocumentTest.java line 1:

> 1: /*

Guess it can be moved to test/jdk/javax/swing/text/DefaultStyledDocument/
Also, rename it something like TestDocNegLenCharAttr or something similar.

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

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


From tr at openjdk.org  Wed Aug 17 06:52:17 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Aug 2022 06:52:17 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v2]
In-Reply-To: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
Message-ID: <v9KjOSu4fJLG7BNdnGHcYazKDrAlP25N24uSSVLVPsU=.fece204a-44b0-44cd-8519-74161bcaba78@github.com>

> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.

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

  Moved test to test/jdk/javax/swing/DefaultStyledDocument

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9830/files
  - new: https://git.openjdk.org/jdk/pull/9830/files/2faa3400..68a4b08f

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

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

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


From tr at openjdk.org  Wed Aug 17 06:57:00 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Aug 2022 06:57:00 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v3]
In-Reply-To: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
Message-ID: <higPvp2A1sm5NF3EHIWSq1UdFlMfFGZgE_7fxRXpxI0=.40258fbe-413b-40d6-919c-d00d9fc9ea2b@github.com>

> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.

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

 - Merge branch 'branch_8291792' of github.com:TejeshR13/jdk into branch_8291792
 - Moved test to test/jdk/javax/swing/DefaultStyledDocument

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9830/files
  - new: https://git.openjdk.org/jdk/pull/9830/files/68a4b08f..3cbc7c51

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

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

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


From psadhukhan at openjdk.org  Wed Aug 17 07:05:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 17 Aug 2022 07:05:47 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v3]
In-Reply-To: <higPvp2A1sm5NF3EHIWSq1UdFlMfFGZgE_7fxRXpxI0=.40258fbe-413b-40d6-919c-d00d9fc9ea2b@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <higPvp2A1sm5NF3EHIWSq1UdFlMfFGZgE_7fxRXpxI0=.40258fbe-413b-40d6-919c-d00d9fc9ea2b@github.com>
Message-ID: <35SkZKs8KfW8SLCSEgp8bcyc7n5mxgo9931Buu20uFg=.d745ca04-53ce-4162-9db2-97613b1f467c@github.com>

On Wed, 17 Aug 2022 06:57:00 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch 'branch_8291792' of github.com:TejeshR13/jdk into branch_8291792
>  - Moved test to test/jdk/javax/swing/DefaultStyledDocument

src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java line 500:

> 498:      */
> 499:     public void setCharacterAttributes(int offset, int length, AttributeSet s, boolean replace) {
> 500:         if (length <= 0) {

@param length the length &gt;= 0 javadoc should it not be then > 0 ?

test/jdk/javax/swing/text/DefaultStyledDocument/DocNegLenCharAttrTest.java line 47:

> 45:  */
> 46: public class DocNegLenCharAttrTest {
> 47:     private static DefaultStyledDocument doc;

guess it can be local variable in test()

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

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


From duke at openjdk.org  Wed Aug 17 08:36:02 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 08:36:02 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v20]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <R10gGGlp_Gn15qYKi9smSb2pSBXiuB8g35GF5w0EhAo=.e889339a-b70d-4b96-8291-f0c7937e9d06@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

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

  comment added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/d749cc38..8ac27853

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=18-19

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

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


From duke at openjdk.org  Wed Aug 17 08:38:56 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 08:38:56 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v20]
In-Reply-To: <R10gGGlp_Gn15qYKi9smSb2pSBXiuB8g35GF5w0EhAo=.e889339a-b70d-4b96-8291-f0c7937e9d06@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <R10gGGlp_Gn15qYKi9smSb2pSBXiuB8g35GF5w0EhAo=.e889339a-b70d-4b96-8291-f0c7937e9d06@github.com>
Message-ID: <kVq-Vh5DAE9WD7DiM-I-6rwU4sUtoDJ4nYe186M1haA=.3aaaf30c-34ba-4465-aa33-7669d93cc471@github.com>

On Wed, 17 Aug 2022 08:36:02 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment added

@prsadhuk Comment added for the changes.

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

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


From duke at openjdk.org  Wed Aug 17 09:08:00 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 09:08:00 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v21]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <DMiPctTWODrJaVbdso4mVU0I-mB_I5Asy-6vmHkLxxA=.97a8dda8-7375-4bd3-a03e-8e524339ffff@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the file size is 0.0 KB.
> Manual Test Case "FileSizeCheck.java" created.

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

  whitespace error removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/8ac27853..497c6864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=19-20

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

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


From tr at openjdk.org  Wed Aug 17 10:06:34 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Aug 2022 10:06:34 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v3]
In-Reply-To: <35SkZKs8KfW8SLCSEgp8bcyc7n5mxgo9931Buu20uFg=.d745ca04-53ce-4162-9db2-97613b1f467c@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <higPvp2A1sm5NF3EHIWSq1UdFlMfFGZgE_7fxRXpxI0=.40258fbe-413b-40d6-919c-d00d9fc9ea2b@github.com>
 <35SkZKs8KfW8SLCSEgp8bcyc7n5mxgo9931Buu20uFg=.d745ca04-53ce-4162-9db2-97613b1f467c@github.com>
Message-ID: <nPBXuug8bOl1duE2MzCdhaT3ClWo4zsP2xUbbDE6wzw=.7441a109-2285-4f91-800b-f241f60976aa@github.com>

On Wed, 17 Aug 2022 07:02:23 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'branch_8291792' of github.com:TejeshR13/jdk into branch_8291792
>>  - Moved test to test/jdk/javax/swing/DefaultStyledDocument
>
> src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java line 500:
> 
>> 498:      */
>> 499:     public void setCharacterAttributes(int offset, int length, AttributeSet s, boolean replace) {
>> 500:         if (length <= 0) {
> 
> @param length the length &gt;= 0 javadoc should it not be then > 0 ?

Yeah, its should be > 0 in java doc. Will update it accordingly. Then should I raise a CSR......?

> test/jdk/javax/swing/JTextPane/DefaultStyledDocumentTest.java line 1:
> 
>> 1: /*
> 
> Guess it can be moved to test/jdk/javax/swing/text/DefaultStyledDocument/
> Also, rename it something like TestDocNegLenCharAttr or something similar.

Updated.

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

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


From psadhukhan at openjdk.org  Wed Aug 17 10:59:03 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 17 Aug 2022 10:59:03 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
Message-ID: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>

Label.foreground UIProperty is not honored by Nimbus L&F.
Added support for setting JLabel foreground color for Nimbus L&F

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

Commit messages:
 - Fix
 - 7175396: The text on label is not painted red for Nimbus LaF.

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

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


From psadhukhan at openjdk.org  Wed Aug 17 11:00:18 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 17 Aug 2022 11:00:18 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v3]
In-Reply-To: <nPBXuug8bOl1duE2MzCdhaT3ClWo4zsP2xUbbDE6wzw=.7441a109-2285-4f91-800b-f241f60976aa@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <higPvp2A1sm5NF3EHIWSq1UdFlMfFGZgE_7fxRXpxI0=.40258fbe-413b-40d6-919c-d00d9fc9ea2b@github.com>
 <35SkZKs8KfW8SLCSEgp8bcyc7n5mxgo9931Buu20uFg=.d745ca04-53ce-4162-9db2-97613b1f467c@github.com>
 <nPBXuug8bOl1duE2MzCdhaT3ClWo4zsP2xUbbDE6wzw=.7441a109-2285-4f91-800b-f241f60976aa@github.com>
Message-ID: <88qKVlQ8w_VtFoWBYksPWw5dQMGlfhwBVObYx1R7OJU=.ea0301ec-ebde-441c-bbe9-932422d189c0@github.com>

On Wed, 17 Aug 2022 10:04:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/text/DefaultStyledDocument.java line 500:
>> 
>>> 498:      */
>>> 499:     public void setCharacterAttributes(int offset, int length, AttributeSet s, boolean replace) {
>>> 500:         if (length <= 0) {
>> 
>> @param length the length &gt;= 0 javadoc should it not be then > 0 ?
>
> Yeah, its should be > 0 in java doc. Will update it accordingly. Then should I raise a CSR......?

probably yes

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

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


From duke at openjdk.org  Wed Aug 17 11:10:33 2022
From: duke at openjdk.org (ScientificWare)
Date: Wed, 17 Aug 2022 11:10:33 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v6]
In-Reply-To: <JTiG4xb_kwM-gHYfR7dP_c8H3tjXcuVeY3C8I5f0wzA=.b7afc4b0-4b2e-4ab0-b991-2d954b81b290@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
 <JTiG4xb_kwM-gHYfR7dP_c8H3tjXcuVeY3C8I5f0wzA=.b7afc4b0-4b2e-4ab0-b991-2d954b81b290@github.com>
Message-ID: <oIURhYDbxHyD7aNLZ6NrySTc-11IAJB5YqrLbmDV76Q=.ca0990a5-95c3-4f40-ba29-013133d97dc6@github.com>

On Tue, 16 Aug 2022 23:15:38 GMT, SWinxy <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes whitespace.
>>   
>>   Remove a whitespace at the end of the file
>
> That's a bit sus for the enhanced switch statement to be significantly slower (7.5x more time than the map). Your methodology still shows that you aren't creating new objects for each invocation and returning the same objects each time. Is that accurate to your performance table?

@SWinxy All my apologies, I skipped testing CASE + RGB implementation. I posted it but not tested (previous results were about CASE + Hex.
I updated my  table including your workaround suggestion.
- The results of CASE + RGB are still under Map.
- But Map + your workaround gives good results.

All the stringToColor codes are available, feel free to make a test.

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

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


From duke at openjdk.org  Wed Aug 17 11:28:27 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Aug 2022 11:28:27 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
In-Reply-To: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
Message-ID: <P0W2W7KMj4lNbqUxnsJ2aH1BsJnMqEzmaCtVVlAXzDE=.667192f9-d302-4a05-9017-f4ebcfbf0994@github.com>

On Thu, 11 Aug 2022 06:53:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `keyListener` was added under [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its usages were removed in [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)

LGTM

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

Marked as reviewed by stsypanov at github.com (no known OpenJDK username).

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


From tr at openjdk.org  Wed Aug 17 11:48:21 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Aug 2022 11:48:21 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
Message-ID: <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>

> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.

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

  Updated based on review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9830/files
  - new: https://git.openjdk.org/jdk/pull/9830/files/3cbc7c51..e812f009

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

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

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


From duke at openjdk.org  Wed Aug 17 11:59:00 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 11:59:00 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions which
 are not inherited
Message-ID: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>

Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .

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

Commit messages:
 - Doc update for Null Pointer Exception

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

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


From duke at openjdk.org  Wed Aug 17 12:03:18 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 12:03:18 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited
In-Reply-To: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
Message-ID: <mofDt7y7-2aohzjtQCiG58c75-1laA8khY_cJGJJFxk=.97a27ffc-96ca-4e07-8833-00a7c7c7eb90@github.com>

On Wed, 17 Aug 2022 11:49:28 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .

1) In javax.swing.JSpinner.DefaultEditor.getBaselineResizeBehavior() method, the exception tag has been removed. Neither this method nor any of the ancestor class definition of this method declared exception tag in description.

2) For javax.swing.border.TitledBorder.getBaseline(java.awt.Component,int,int) method, the ancestor class definition of this method didn't declare exception tag for NPE. So, {@inheritDoc} didn't inherit anything. 
However, javax.swing.border.TitledBorder.getBaseline(java.awt.Component,int,int) throws NPE if Component is null. NPE tag has been changed accordingly.

3) For javax.swing.border.TitledBorder.getBaselineResizeBehavior(java.awt.Component) method, the {@inheritDoc} didn't inherit anything because there was no exception tag in ancestor class method definition.
As TitledBorder extends AbstractBorder, getBaselineResizeBehavior(java.awt.Component) method throws an exception if Component is null but the exception tag was missing for method description in AbstractBorder.
So, exception tag for NPE added for getBaselineResizeBehavior(java.awt.Component) method in AbstractBorder.
Now in  javax.swing.border.TitledBorder.getBaselineResizeBehavior(java.awt.Component) method, the {@inheritDoc} inherits NPE tag from AbstractBorder.

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

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


From duke at openjdk.org  Wed Aug 17 12:07:27 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Aug 2022 12:07:27 GMT
Subject: RFR: 8292376: A few Swing methods use inheritDoc on exceptions
 which are not inherited [v2]
In-Reply-To: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
References: <W1yenf_2rr8sMDSjJcKF-IGZa_mGYSG572YrlWcxH7w=.9388229b-7cd5-42b7-aaf8-00cdd955278a@github.com>
Message-ID: <NL96eVu0zHujvOrGCR9P98jZRcVbf8rezkzLIPzA7OA=.30b5f2b1-84c1-42a3-babf-ccf9e96ff6f6@github.com>

> Document update for getBaselineResizeBehavior() and getBaseline() method description in JSpinner, AbstractBorder and TitledBorder .

Abhishek Kumar 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/9902/files
  - new: https://git.openjdk.org/jdk/pull/9902/files/737770f2..f4e9d288

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

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

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


From psadhukhan at openjdk.org  Wed Aug 17 12:50:27 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 17 Aug 2022 12:50:27 GMT
Subject: Integrated: 7132413: [macosx]
 closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS
In-Reply-To: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
References: <lFJDlTvkQK2byVAp4E22Ou7sALhQnBhqcE6xecR6Gj8=.11363546-5b75-4b65-86da-c8862c0ded6b@github.com>
Message-ID: <Kq5Xl2ZqoG5bg2CUUgjOa3aR-tVvup3g462TW-AE750=.0cd9975a-5de1-4516-ac0d-87d5956b1f0b@github.com>

On Wed, 13 Jul 2022 12:49:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> It was seen that some of the icons like disabled-selected:,  rollover icons are not shown.
> Fixed to get the default selected icon and use that if in case the icon for that state is not set.

This pull request has now been integrated.

Changeset: bf7d6d3a
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf7d6d3a0f947ab4a30f27bce6650798289cc7fd
Stats:     438 lines in 10 files changed: 436 ins; 0 del; 2 mod

7132413: [macosx] closed/javax/swing/AbstractButton/5049549/bug5049549.java fails on MacOS

Reviewed-by: azvegint, dnguyen

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

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


From honkar at openjdk.org  Wed Aug 17 19:55:14 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 17 Aug 2022 19:55:14 GMT
Subject: RFR: 8292328 : AccessibleActionsTest.java test instruction for
 show popup on JLabel did not specify shift key
In-Reply-To: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
References: <PRgGYMbpY_r_y1Rb7qpIn7ffmOZiqisA5i1QBuwFFHY=.3df5c35c-bcb8-4eba-be25-23e13db36f99@github.com>
Message-ID: <WUTSKnDNP27dM3hIL-3CLJnfNQqGC8fy4Fz7FJaiOgw=.ba717933-1266-4881-a21f-37528093bab7@github.com>

On Sat, 13 Aug 2022 22:44:52 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Corrected the test instruction to show the popup menu on JLabel when voice over is enabled .
> 
> @shurymury

Tested on Mac 12.3, **(VO+Shift+m)** for menu expansion works. The first and third tests work fine. In the second test (JTree), first level of expansion works on pressing **(VO+space)** but the expansion to leaf nodes doesn't occur on subsequent **(VO+space)**.

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

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


From dnguyen at openjdk.org  Wed Aug 17 22:37:46 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 17 Aug 2022 22:37:46 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
Message-ID: <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>

> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
> 
> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
> 
> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.

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

  Updated copyright date. Added MacOS text to test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9473/files
  - new: https://git.openjdk.org/jdk/pull/9473/files/fe0d2f81..0eae1016

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9473&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9473&range=05-06

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

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


From dnguyen at openjdk.org  Wed Aug 17 22:37:46 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 17 Aug 2022 22:37:46 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v6]
In-Reply-To: <Ufr-ac-3TAbM6XCiZHyZcgo1HkU--QV7M3tgoaMuRUw=.ebc49b65-1b27-4bf9-8e39-458fd49e2d86@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <9_BjKy-Zu9Q4YJ1BfLgvVFPAaHeTw3nv6i8SH_XzP4o=.1f4e951d-58eb-4b29-b15f-13ab54cfa2a1@github.com>
 <Ufr-ac-3TAbM6XCiZHyZcgo1HkU--QV7M3tgoaMuRUw=.ebc49b65-1b27-4bf9-8e39-458fd49e2d86@github.com>
Message-ID: <qLFcde_B1h_L98rw7wP7jOALTIOV3dg2dGwH0lR9PFw=.4165c106-0341-4fc5-9e24-019e7fe06137@github.com>

On Wed, 17 Aug 2022 00:14:30 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Tested on Mac 12.3. The editable combobox looks quite close to the non editable one.
> 
> > Ideally, the textfield also should have a focus border around it similar to button, so it will look uniform, so instead of removing border from button, we can try to draw focus border around textfield.
> 
> Just a thought: As @prsadhuk suggested earlier, carrying forward the focus ring style & thickness of the button over to the textfield might help in giving the editable combobox (textfield + button) a unified look when it has focus.
> 
> ![image](https://user-images.githubusercontent.com/95945681/185005697-be9eb779-15fb-4792-95df-77c3917a80cc.png)
> 
> ![image](https://user-images.githubusercontent.com/95945681/185005741-1bb845c2-4aad-41b0-bf0e-1e965dc7c9c2.png)
> 
> Minor changes: Copyright year for AquaComboBoxUI needs to be updated Adding MacOS test - either in the instructionText or summary of the test.

Updated the copyright and text. For the border, I brought this topic up in previous talks and it was noted that the current appearance is sufficient, at least for now. The editable combobox uses the default textfield's focusborder and an additional issue can be created for updating the focus border to match the button's.

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

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


From honkar at openjdk.org  Wed Aug 17 22:44:14 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 17 Aug 2022 22:44:14 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
Message-ID: <b7hrJtO4R3X1KMRqmWhyvIv91Xz9uAS67cuCRdbhWsM=.f44626b3-822a-45a1-bf54-2e2de10da002@github.com>

On Wed, 17 Aug 2022 22:37:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright date. Added MacOS text to test.

Marked as reviewed by honkar (Author).

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

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


From tr at openjdk.org  Thu Aug 18 06:02:11 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 18 Aug 2022 06:02:11 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v3]
In-Reply-To: <88qKVlQ8w_VtFoWBYksPWw5dQMGlfhwBVObYx1R7OJU=.ea0301ec-ebde-441c-bbe9-932422d189c0@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <higPvp2A1sm5NF3EHIWSq1UdFlMfFGZgE_7fxRXpxI0=.40258fbe-413b-40d6-919c-d00d9fc9ea2b@github.com>
 <35SkZKs8KfW8SLCSEgp8bcyc7n5mxgo9931Buu20uFg=.d745ca04-53ce-4162-9db2-97613b1f467c@github.com>
 <nPBXuug8bOl1duE2MzCdhaT3ClWo4zsP2xUbbDE6wzw=.7441a109-2285-4f91-800b-f241f60976aa@github.com>
 <88qKVlQ8w_VtFoWBYksPWw5dQMGlfhwBVObYx1R7OJU=.ea0301ec-ebde-441c-bbe9-932422d189c0@github.com>
Message-ID: <KNY55QxlIsLnjB9VM2QbYKfqzA-fORwPkPj-pSnb4fk=.702d72b2-023b-4bbe-8eb6-003a15693924@github.com>

On Wed, 17 Aug 2022 10:56:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yeah, its should be > 0 in java doc. Will update it accordingly. Then should I raise a CSR......?
>
> probably yes

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From tr at openjdk.org  Thu Aug 18 06:02:15 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 18 Aug 2022 06:02:15 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v3]
In-Reply-To: <35SkZKs8KfW8SLCSEgp8bcyc7n5mxgo9931Buu20uFg=.d745ca04-53ce-4162-9db2-97613b1f467c@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <higPvp2A1sm5NF3EHIWSq1UdFlMfFGZgE_7fxRXpxI0=.40258fbe-413b-40d6-919c-d00d9fc9ea2b@github.com>
 <35SkZKs8KfW8SLCSEgp8bcyc7n5mxgo9931Buu20uFg=.d745ca04-53ce-4162-9db2-97613b1f467c@github.com>
Message-ID: <XhrDGOUdilxPX8bfHiuWPMlazaKXFNLeRC_d2C8gT54=.f7259ae1-99f8-4b2b-8192-a1a9bf687fab@github.com>

On Wed, 17 Aug 2022 07:02:44 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge branch 'branch_8291792' of github.com:TejeshR13/jdk into branch_8291792
>>  - Moved test to test/jdk/javax/swing/DefaultStyledDocument
>
> test/jdk/javax/swing/text/DefaultStyledDocument/DocNegLenCharAttrTest.java line 47:
> 
>> 45:  */
>> 46: public class DocNegLenCharAttrTest {
>> 47:     private static DefaultStyledDocument doc;
> 
> guess it can be local variable in test()

Updated.

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From psadhukhan at openjdk.org  Thu Aug 18 12:09:17 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 18 Aug 2022 12:09:17 GMT
Subject: RFR: 4850101: Setting mnemonic to VK_F4 underlines the letter S in
 a button. [v2]
In-Reply-To: <5ZZiPID1A-WKy5U0TOtgXqOf-v-bXhfsH797zQ-yHcA=.b1c740bc-4a2d-48be-a7f2-9c79a1b49738@github.com>
References: <fwQauIncMy46_rhIyR9OW70AWjzoa3NO4FfMjIZ3wkE=.e4a6d40e-a004-4d6c-b543-1e8a7f31cca7@github.com>
 <5ZZiPID1A-WKy5U0TOtgXqOf-v-bXhfsH797zQ-yHcA=.b1c740bc-4a2d-48be-a7f2-9c79a1b49738@github.com>
Message-ID: <5m6p9sXzUxbgCQWWp4pcYKKwdLYD5qGyGVh4aH7_0nY=.225d6e26-67de-4089-be31-37dbbb68f72d@github.com>

On Thu, 4 Aug 2022 20:54:05 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modify check for lowercase character
>
> Sounds reasonable to me although I'm not an expert on mnemonic handling.

@prrace The code is changed since last approved..Do you have any objection?

-------------

PR: https://git.openjdk.org/jdk/pull/9712


From psadhukhan at openjdk.org  Thu Aug 18 12:12:14 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 18 Aug 2022 12:12:14 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v6]
In-Reply-To: <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
Message-ID: <KyCF_w_iWIWcxAPzpwDJ1WMf3pZmCmsr2y2TaDoNyqo=.f4ed4a61-ba1d-435d-abf6-36bd4da382c2@github.com>

On Thu, 28 Jul 2022 04:07:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
>> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove implNote tag

We were not sure if -ve divider size can be used by third party implementation. It probably will be considered a compatibility issue as mentioned earlier. 
@prrace Will you be ok to throw IAE instead of ignoring -ve value as suggested or should we keep it as it is now in this PR?

-------------

PR: https://git.openjdk.org/jdk/pull/9566


From psadhukhan at openjdk.org  Thu Aug 18 12:56:18 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 18 Aug 2022 12:56:18 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
Message-ID: <HOAeHMyB5-gSwEAridM-kis7VM6U49JQqRugM36ccGQ=.90a867d6-005a-484b-a854-67e6289e1550@github.com>

On Wed, 17 Aug 2022 11:48:21 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From honkar at openjdk.org  Thu Aug 18 23:03:34 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 18 Aug 2022 23:03:34 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v4]
In-Reply-To: <X2reQ_V2C6LQPnU_yAqgExkxBKDAHVvfI32Z9XcMvH0=.3bf6bdb2-77ff-4662-b88d-fff7ad8f2a57@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <nBNn8-oV-bIy5ZDYRzaZMa1vSArL4RooVq8B8psA8_8=.c64ecb8d-d509-4e72-8447-58defb23608f@github.com>
 <uMQLvxfz86IoFQxxfz74vepg3eCBUfX_A5zeNjEa9YE=.aec1ae55-de2b-4de9-b064-07832a3a201f@github.com>
 <X2reQ_V2C6LQPnU_yAqgExkxBKDAHVvfI32Z9XcMvH0=.3bf6bdb2-77ff-4662-b88d-fff7ad8f2a57@github.com>
Message-ID: <SZ4MMpwVbtESr4pkCofAaCE13Vo4GiS4Zpw8dXVP8MQ=.8c0f91a4-be1e-4e6a-8bce-b8834ef3cca3@github.com>

On Mon, 15 Aug 2022 18:39:21 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> As suggested, further changes to PassFailJFrame (creating a new version) will be dealt as a separate issue after evaluating impact of redesigning the framework.

This will be taken up as a separate task and does not affect the present PR. 
Following are proposed redesign changes to PassFailJFrame test framework.

1.  Addition of JSplitPane ?  for instruction and test window
2.  If an exception is thrown before awaitAndCheck is called, the test will hang eventually. Clicking the Pass/Fail buttons doesn't close the UI since it's inside awaitAndCheck. This needs to be addressed when redesigning the framework.
3. Functional Style Paradigm: so that the code to create the test UI (window or component) can be passed as a method reference to constructor.
4.  Handler for the close button on test UI windows / frames (obtained via a factory method which would fail the test and dispose the UI). Currently it's to be handled by each test (usually remain unhandled).
5.  Better formatting option for instruction window ? support for html tags.

The plan is to start the changes as a new and separate test framework to minimize the impact on existing manual test cases using PassFailJFrame. If anyone has anything additional, please feel free to add or provide feedback on this discussion.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From duke at openjdk.org  Fri Aug 19 06:56:38 2022
From: duke at openjdk.org (Joe)
Date: Fri, 19 Aug 2022 06:56:38 GMT
Subject: RFR: 8289562: Change bugs.java.com and bugreport.java.com URL's to
 https [v2]
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <SNHwtcq72zY7FsKGHrue2rTaexjNxMUZ4EhdP4GPP2k=.b2171fb9-b781-4f9c-afca-f8f1832ba844@github.com>

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

Joe 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 master
 - Merge branch 'openjdk:master' into master
 - changed the hrl from http to https JDK-8289562

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9445/files
  - new: https://git.openjdk.org/jdk/pull/9445/files/324f877c..07b7be0c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9445&range=00-01

  Stats: 142897 lines in 2088 files changed: 75388 ins; 52973 del; 14536 mod
  Patch: https://git.openjdk.org/jdk/pull/9445.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9445/head:pull/9445

PR: https://git.openjdk.org/jdk/pull/9445


From psadhukhan at openjdk.org  Fri Aug 19 07:48:15 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 19 Aug 2022 07:48:15 GMT
Subject: RFR: 7175397: The divider color is not changed to green when dragging
 for Nimbus LaF.
Message-ID: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>

SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415

All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.

-------------

Commit messages:
 - 7175397: The divider color is not changed to green when dragging for Nimbus LaF.

Changes: https://git.openjdk.org/jdk/pull/9937/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9937&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7175397
  Stats: 26 lines in 2 files changed: 25 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9937.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9937/head:pull/9937

PR: https://git.openjdk.org/jdk/pull/9937


From duke at openjdk.org  Fri Aug 19 08:58:59 2022
From: duke at openjdk.org (Joe)
Date: Fri, 19 Aug 2022 08:58:59 GMT
Subject: Integrated: 8289562: Change bugs.java.com and bugreport.java.com URL's
 to https
In-Reply-To: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
References: <JvByCea15NlNGABxsC0cc3fmCWcbNe_jnPrJJJ5JsM8=.291447d4-367c-4634-a750-f78885c2ada4@github.com>
Message-ID: <3PKzwl7RxEVyWEBTVdySoL1eKjal-7IRGDANL2ABqG8=.7dc34842-62c6-40a5-8ce3-1bf0e9f58852@github.com>

On Mon, 11 Jul 2022 08:04:20 GMT, Joe <duke at openjdk.org> wrote:

> 8289562: Change bugs.java.com and bugreport.java.com URL's to https

This pull request has now been integrated.

Changeset: 1f484dae
Author:    Joe <joe.cherian at oracle.com>
Committer: Fairoz Matte <fmatte at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f484dae4efaa60cf18a3d4df947c05f1497bd5b
Stats:     18 lines in 17 files changed: 0 ins; 0 del; 18 mod

8289562: Change bugs.java.com and bugreport.java.com URL's to https

Co-authored-by: Joe Cherian <joe.cherian at oracle.com>
Reviewed-by: prr, jjg, naoto, iris

-------------

PR: https://git.openjdk.org/jdk/pull/9445


From psadhukhan at openjdk.org  Fri Aug 19 10:31:49 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 19 Aug 2022 10:31:49 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v21]
In-Reply-To: <DMiPctTWODrJaVbdso4mVU0I-mB_I5Asy-6vmHkLxxA=.97a8dda8-7375-4bd3-a03e-8e524339ffff@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DMiPctTWODrJaVbdso4mVU0I-mB_I5Asy-6vmHkLxxA=.97a8dda8-7375-4bd3-a03e-8e524339ffff@github.com>
Message-ID: <f6QzWklfX7Pv1NthMkj7XYQYB8vpK_3yUQ69hqBCV2U=.82c72d90-1707-404c-a40a-e9509d8b74ac@github.com>

On Wed, 17 Aug 2022 09:08:00 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace error removed

Marked as reviewed by psadhukhan (Reviewer).

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 60:

> 58:                     "Test 8: If the size of 8-File-1000-KB shows 1.0 MB\n" +
> 59:                     "Test 9: If the size of 9-File-2.8-MB shows 2.8 MB\n\n" +
> 60:                            "press PASS.\n\n";

I think it's better to have 1st-Empty-File, 2nd-File-1-Byte etc but it's upto you..

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Aug 19 10:40:14 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 19 Aug 2022 10:40:14 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v22]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Updated as per review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/497c6864..5526919c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=20-21

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Aug 19 10:40:15 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 19 Aug 2022 10:40:15 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v21]
In-Reply-To: <f6QzWklfX7Pv1NthMkj7XYQYB8vpK_3yUQ69hqBCV2U=.82c72d90-1707-404c-a40a-e9509d8b74ac@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DMiPctTWODrJaVbdso4mVU0I-mB_I5Asy-6vmHkLxxA=.97a8dda8-7375-4bd3-a03e-8e524339ffff@github.com>
 <f6QzWklfX7Pv1NthMkj7XYQYB8vpK_3yUQ69hqBCV2U=.82c72d90-1707-404c-a40a-e9509d8b74ac@github.com>
Message-ID: <8RzOawbKAC3g7SSPqBcgKsFwiCA9AwvLx6sA4CuFxzc=.75786cad-5a16-492c-8173-8c99289329df@github.com>

On Fri, 19 Aug 2022 10:27:53 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   whitespace error removed
>
> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 60:
> 
>> 58:                     "Test 8: If the size of 8-File-1000-KB shows 1.0 MB\n" +
>> 59:                     "Test 9: If the size of 9-File-2.8-MB shows 2.8 MB\n\n" +
>> 60:                            "press PASS.\n\n";
> 
> I think it's better to have 1st-Empty-File, 2nd-File-1-Byte etc but it's upto you..

I have updated the suggested changes.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Fri Aug 19 16:49:17 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Aug 2022 16:49:17 GMT
Subject: RFR: 8292304: [REDO] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
In-Reply-To: <hoWXjz5E3xFvx9_1GiiCpl5HM4oyWFguc53_I7B8oRA=.2db225d0-0d6c-484c-8804-c73e4c31f349@github.com>
References: <hoWXjz5E3xFvx9_1GiiCpl5HM4oyWFguc53_I7B8oRA=.2db225d0-0d6c-484c-8804-c73e4c31f349@github.com>
Message-ID: <H7ospiFNHT4syN0aX5A8eIIQ5xiXD2TYCqlP0PAYEQI=.842c4d27-2407-49c7-867c-eb4d21a9037d@github.com>

On Tue, 16 Aug 2022 08:26:08 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> See also the [original pull request](https://github.com/openjdk/jdk/pull/9362) where the change is explained and discussed in details.
> 
> Compared to the original version of this fix I
> * changed the error reporting from `printStackTrace()` to `System.out.println()` as per @prrace request,
> * fixed the test to use `AtomicInteger` for the counter of disposer records as `+=` and `--` operations on a `volatile int` do not guarantee value's integrity, which caused the test to often fail.
> 
> `test/jdk/sun/java2d/Disposer/TestDisposerRace.java` now passes successfully on MacOS and Linux.

I ran this and the new tests with all our other tests and the job passed so this looks fine now.
Still, I suggest to wait for Monday before pushing :-)

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9890


From amenkov at openjdk.org  Fri Aug 19 23:21:31 2022
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 19 Aug 2022 23:21:31 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <TrZ_D2g9H4v54x1t4KeoA-OTHI31DTVMf7aFU6sjq2o=.e1f500cc-a526-42a3-8496-166c1c6f687b@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Marked as reviewed by amenkov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9816


From honkar at openjdk.org  Fri Aug 19 23:57:11 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 19 Aug 2022 23:57:11 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT Non-resizable
 frame are different
Message-ID: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>

On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  

Earlier the insets returned when frame.getInsets() was called was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.

-------------

Commit messages:
 - Non-Resizable AWT Frame insets fix

Changes: https://git.openjdk.org/jdk/pull/9954/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9954&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288325
  Stats: 49 lines in 2 files changed: 26 ins; 6 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9954.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9954/head:pull/9954

PR: https://git.openjdk.org/jdk/pull/9954


From jpai at openjdk.org  Sat Aug 20 02:02:30 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Aug 2022 02:02:30 GMT
Subject: RFR: 8292350: Use static methods for hashCode/toString primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <SEjLbNITp0dcxRVQ8zXuhxapMh9F2aS-kfGC1kVRLII=.8edb1b3a-be15-4a3c-9f8f-d01cca115657@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

Looks fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9816


From aturbanov at openjdk.org  Sat Aug 20 10:08:52 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 20 Aug 2022 10:08:52 GMT
Subject: Integrated: 8292350: Use static methods for hashCode/toString
 primitives
In-Reply-To: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
References: <rkq5e3c6aKoNCGEhSu8b0CmsUznXtto7WQzRSmkx538=.1cff5bbf-5ba2-41bd-84a3-e1511b10c479@github.com>
Message-ID: <Lru9gwGomh6rLr2cE368n4Z6RopDrctLbqorcYnvw-k=.e1e94fb2-34f4-4dc5-bc86-4106b816920f@github.com>

On Wed, 10 Aug 2022 08:01:41 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> It's a bit shorter and clearer.

This pull request has now been integrated.

Changeset: 37c0a136
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/37c0a13647e74fd02823a3f621e986f96904b933
Stats:     8 lines in 4 files changed: 0 ins; 0 del; 8 mod

8292350: Use static methods for hashCode/toString primitives

Reviewed-by: prr, rriggs, amenkov, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/9816


From aturbanov at openjdk.org  Sun Aug 21 09:54:06 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 21 Aug 2022 09:54:06 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF.
In-Reply-To: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
Message-ID: <fPtYVOPVE2ZmT292a9oRlqAWIZuAlEQmJhy56txhnPM=.a3aba6da-b5bc-41ff-b284-15a0b3a7d654@github.com>

On Fri, 19 Aug 2022 07:40:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
> 
> closed test mentioned in JBS is used for fix check.
> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthSplitPaneUI.java line 272:

> 270:             public void paint(Graphics g) {
> 271:                 paintDragDivider(g, 0, 0, getWidth(), getHeight());
> 272:                 if(!isContinuousLayout() && getLastDragLocation() != -1) {

Let's add space after `if`

-------------

PR: https://git.openjdk.org/jdk/pull/9937


From prr at openjdk.org  Sun Aug 21 21:12:48 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 21 Aug 2022 21:12:48 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v22]
In-Reply-To: <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
Message-ID: <1vIZK9GjFmvSFEiDeXaRrYIm6pF9vwHZkOvGjuhKQ_E=.628cf54f-af74-45ca-81bd-51f99a723753@github.com>

On Fri, 19 Aug 2022 10:40:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per review comment

src/java.desktop/share/classes/sun/swing/FilePane.java line 1261:

> 1259: 
> 1260:         private static double formatToDoubleValue(long len) {
> 1261:             return (len / 100L) / 10.0d;

First "formatToDouble" isn't really a very good name for this. 
Perhaps I could provide a better one if I could be sure of what the intent is here but
at the very least this method needs comments explaining what it is doing AND why.

The first (len / 100L) expression means that (eg)
100 and 199 will both become 1 and the return value of the method is 0.1 

So rounding DOWN is happening here, whereas (separately) we round UP for value < 100 ..

So anything from 1  byte to 199 bytes will be 0.1 KB ?

The test doesn't seem to cover this case.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Sun Aug 21 21:26:31 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 21 Aug 2022 21:26:31 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF.
In-Reply-To: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
Message-ID: <zvGXKqyGaF5qOr_kI7qIs8bwCdb0aF4G2oeQgV4l2nk=.37b7ffe6-4eaf-4211-bdb9-bd3427eaf6f2@github.com>

On Fri, 19 Aug 2022 07:40:13 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
> 
> closed test mentioned in JBS is used for fix check.
> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.

src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 21333:


You wrote

The fix relies on continuousLayout property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415


I don't think so .. it was documenting the Nimbus default which is continuous.
Per the javadoc for 
https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JSplitPane.html#setContinuousLayout(boolean)

" The default value of this property is look and feel dependent."

So if Nimbus has had it ON all this time, it is not right to change it.

-------------

PR: https://git.openjdk.org/jdk/pull/9937


From prr at openjdk.org  Sun Aug 21 21:31:30 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 21 Aug 2022 21:31:30 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
In-Reply-To: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
Message-ID: <m5FaWGhdBKPXUyNkSIkCToBUxirQZ5Q1LaF-jIQRiVc=.ac78ad2f-6be1-48c5-8a38-4b11e47ae9fe@github.com>

On Thu, 11 Aug 2022 06:53:16 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `keyListener` was added under [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its usages were removed in [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java line 148:

> 146: 
> 147:         Icon altIcon = b.getIcon();
> 148: 

So what's this about ?

-------------

PR: https://git.openjdk.org/jdk/pull/9832


From prr at openjdk.org  Sun Aug 21 21:37:29 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 21 Aug 2022 21:37:29 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v6]
In-Reply-To: <KyCF_w_iWIWcxAPzpwDJ1WMf3pZmCmsr2y2TaDoNyqo=.f4ed4a61-ba1d-435d-abf6-36bd4da382c2@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
 <KyCF_w_iWIWcxAPzpwDJ1WMf3pZmCmsr2y2TaDoNyqo=.f4ed4a61-ba1d-435d-abf6-36bd4da382c2@github.com>
Message-ID: <4A6WVaJKLPWFrmp_p80scsA5Msqe3gEUOrL94f0E-Hs=.80f4bd20-0990-4019-93fb-5866fec17f29@github.com>

On Thu, 18 Aug 2022 12:08:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> We were not sure if -ve divider size can be used by third party implementation. It probably will be considered a compatibility issue as mentioned earlier.
> @prrace Will you be ok to throw IAE instead of ignoring -ve value as suggested or should we keep it as it is now in this PR?

IAE is just too incompatible. The program would probably stop working if anyone is actually doing that.
If it had been done since day one, yes, but too late now.

I didn't get why some effect like the "visibility" of the divider in some L&F should be allowed to over-rule the specified size.

-------------

PR: https://git.openjdk.org/jdk/pull/9566


From aturbanov at openjdk.org  Sun Aug 21 21:40:43 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 21 Aug 2022 21:40:43 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
 [v2]
In-Reply-To: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
Message-ID: <Mh3c2YhtqAjZHkF466CILvxcIuAk_Ui7ESMvD7aOVU0=.4b23cb63-6f38-4bad-8dde-5fdde200e0a2@github.com>

> Field `keyListener` was added under [JDK-8033699](https://bugs.openjdk.org/browse/JDK-8033699). But then all its usages were removed in [JDK-8249548](https://bugs.openjdk.org/browse/JDK-8249548)

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8292280: Unused field 'keyListener' in BasicRadioButtonUI
  
  reverted unrelated changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9832/files
  - new: https://git.openjdk.org/jdk/pull/9832/files/f5957cd5..fa6deb66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9832&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9832&range=00-01

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9832.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9832/head:pull/9832

PR: https://git.openjdk.org/jdk/pull/9832


From aturbanov at openjdk.org  Sun Aug 21 21:40:45 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 21 Aug 2022 21:40:45 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
 [v2]
In-Reply-To: <m5FaWGhdBKPXUyNkSIkCToBUxirQZ5Q1LaF-jIQRiVc=.ac78ad2f-6be1-48c5-8a38-4b11e47ae9fe@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
 <m5FaWGhdBKPXUyNkSIkCToBUxirQZ5Q1LaF-jIQRiVc=.ac78ad2f-6be1-48c5-8a38-4b11e47ae9fe@github.com>
Message-ID: <o8HCbCeXAeSvA4lOXtOjQHViiVBFd7ruuICy2a8x0UI=.d6750ed4-e80f-474a-9d08-a8a93ce8f260@github.com>

On Sun, 21 Aug 2022 21:27:30 GMT, Phil Race <prr at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292280: Unused field 'keyListener' in BasicRadioButtonUI
>>   
>>   reverted unrelated changes
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java line 148:
> 
>> 146: 
>> 147:         Icon altIcon = b.getIcon();
>> 148: 
> 
> So what's this about ?

I reverted this changes

-------------

PR: https://git.openjdk.org/jdk/pull/9832


From prr at openjdk.org  Sun Aug 21 22:12:33 2022
From: prr at openjdk.org (Phil Race)
Date: Sun, 21 Aug 2022 22:12:33 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v8]
In-Reply-To: <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
Message-ID: <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>

On Thu, 11 Aug 2022 22:27:39 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review changes

A few comments which are mostly (or all?) nit picking about the javadoc of the method.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 265:

> 263:     /**
> 264:      * Position the instruction frame with testWindow (testcase created
> 265:      * window) by the specified position. If testWindow is null, only

The pre-existing docs don't read very well to me and some of it doesn't make sense, so in this update
we should try to fix that.

First sentence would be better as 
"Positions the instruction frame relative to the test window as specified by the {@code position} parameter.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 269:

> 267:      * parameter.
> 268:      * Note: This method should be invoked from the method that creates
> 269:      * testWindow. At test-level, the testWindow must be made visible

I think we should remove that Note sentence - surely the calling method is irrelevant. 
 It is sufficient to explain that 
"This method should be called before making the test window visible".
But why is that ?

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 272:

> 270:      * only after calling this method.
> 271:      *
> 272:      * @param testWindow test window that the test is created. It can be null.

"It can be null" -> "May be {@code null}"

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 273:

> 271:      *
> 272:      * @param testWindow test window that the test is created. It can be null.
> 273:      * @param position  position can either be:

position must be one of

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 278:

> 276:      *                  center and the test window (if not null) is placed to
> 277:      *                  the right of the instruction frame.
> 278:      *

"vertical center" means half way between the top and the bottom which is absolutely not what you mean, is it ?

horizontal center surely ?

But what if the test window is > 0.5 the width of the screen ? Now it is off the edge .. wouldn't it be better
to move the instruction window to the left to accommodate it ?
Although that might be tricky if we don't know its size yet ..

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From duke at openjdk.org  Sun Aug 21 22:54:21 2022
From: duke at openjdk.org (Karl T)
Date: Sun, 21 Aug 2022 22:54:21 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v6]
In-Reply-To: <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
Message-ID: <L20y2Rb8kP7E9zjIfJAjYEkYD10Vhb9Kic2ef9rG-BE=.9b4b01b3-d599-4e66-8d3e-902b4e9565a4@github.com>

On Thu, 28 Jul 2022 04:07:55 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Setting JSplitPane divider size to negative value leads to unexpected results and is not desirable and seems to be not practical.
>> I guess we should return IAE but it might break existing app so fixed to clamp it to 0 incase negative value is tried to be set for divider size.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove implNote tag

All look and feels initially set the divider size to what they need. This is done here:

https://github.com/openjdk/jdk/blob/eab4c0c49934bd6f37a0b6174ca10e5c8708d13b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicSplitPaneUI.java#L357-L358

Each L&F uses its own divider size.
E.g. Windows L&F uses `5`:

https://github.com/openjdk/jdk/blob/0a65e8b282fd41e57108422fbd140527d9697efd/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsLookAndFeel.java#L1247

Or Metal L&F uses `10`:

https://github.com/openjdk/jdk/blob/d4b040f42dd0a9100ad1ffa55de4ae4f20e9f182/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L1371

So a L&F could also use divider size zero to implement an invisible divider.
Don't see a reason, why divider size zero should be no longer allowed...

> I didn't get why some effect like the "visibility" of the divider in some L&F should be allowed to over-rule the specified size.

If the application invokes `JSplitPane.setDividerSize(int)`, then this overrules the divider size specified by the L&F.
There is a field `JSplitPane.dividerSizeSet` that is used for this.

L&Fs do not invoke `JSplitPane.setDividerSize(int)` directly. Instead they invoke `LookAndFeel.installProperty(...)`, which calls `JSplitPane.setUIProperty(...)`, which checks flag `dividerSizeSet` and does not change divider size if the application has invoked `setDividerSize(...)`:

https://github.com/openjdk/jdk/blob/096bca4a9c5e8ac2668dd965df92153ea1d80add/src/java.desktop/share/classes/javax/swing/JSplitPane.java#L1059-L1064

-------------

PR: https://git.openjdk.org/jdk/pull/9566


From duke at openjdk.org  Mon Aug 22 01:01:39 2022
From: duke at openjdk.org (SWinxy)
Date: Mon, 22 Aug 2022 01:01:39 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v6]
In-Reply-To: <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
Message-ID: <nVCzpDMzdY4CIXSx27BsR53YexilKhIyiKF3f_ticDw=.bfb3f7c1-cd41-43ec-9eda-2f807dad5e5a@github.com>

On Tue, 16 Aug 2022 21:37:30 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removes whitespace.
>   
>   Remove a whitespace at the end of the file

I mean I think I would *prefer* the switch over a map (it looks nicer to me). My crude tests showed that the switch is indeed slower, breaking my conception that switch statements are the peak of performance. Other than [this request](#issuecomment-1216011827), I have no further comments.

-------------

PR: https://git.openjdk.org/jdk/pull/9825


From psadhukhan at openjdk.org  Mon Aug 22 03:37:11 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 22 Aug 2022 03:37:11 GMT
Subject: RFR: 4797982: Setting negative size of JSplitPane divider leads to
 unexpected results. [v6]
In-Reply-To: <4A6WVaJKLPWFrmp_p80scsA5Msqe3gEUOrL94f0E-Hs=.80f4bd20-0990-4019-93fb-5866fec17f29@github.com>
References: <xNpueENHApki0t4o5YumSdcseQzRRiLWrzxMKOFT-xc=.239da686-d95a-4e93-a107-32a7c298414c@github.com>
 <qMmCbrYS1zzPFM3mgNwV1cIzgGfBMXZj3qXsDfIwAGA=.b8a8be47-3348-4778-b34f-4d2a126791a8@github.com>
 <KyCF_w_iWIWcxAPzpwDJ1WMf3pZmCmsr2y2TaDoNyqo=.f4ed4a61-ba1d-435d-abf6-36bd4da382c2@github.com>
 <4A6WVaJKLPWFrmp_p80scsA5Msqe3gEUOrL94f0E-Hs=.80f4bd20-0990-4019-93fb-5866fec17f29@github.com>
Message-ID: <J7qcTGCMUbm6Sg2JyKbufP694-wVZzaZ6WwHOKxuQM8=.bd4baed1-fdab-4ea9-825f-ce27f2c5cd65@github.com>

On Sun, 21 Aug 2022 21:34:10 GMT, Phil Race <prr at openjdk.org> wrote:

>> We were not sure if -ve divider size can be used by third party implementation. It probably will be considered a compatibility issue as mentioned earlier. 
>> @prrace Will you be ok to throw IAE instead of ignoring -ve value as suggested or should we keep it as it is now in this PR?
>
>> We were not sure if -ve divider size can be used by third party implementation. It probably will be considered a compatibility issue as mentioned earlier.
>> @prrace Will you be ok to throw IAE instead of ignoring -ve value as suggested or should we keep it as it is now in this PR?
> 
> IAE is just too incompatible. The program would probably stop working if anyone is actually doing that.
> If it had been done since day one, yes, but too late now.
> 
> I didn't get why some effect like the "visibility" of the divider in some L&F should be allowed to over-rule the specified size.

@prrace Probably we could reinstate @implNote to the javadoc as I did earlier, to allow 3rd party L&F -ve divider size?

-------------

PR: https://git.openjdk.org/jdk/pull/9566


From duke at openjdk.org  Mon Aug 22 09:48:46 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Mon, 22 Aug 2022 09:48:46 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v22]
In-Reply-To: <1vIZK9GjFmvSFEiDeXaRrYIm6pF9vwHZkOvGjuhKQ_E=.628cf54f-af74-45ca-81bd-51f99a723753@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
 <1vIZK9GjFmvSFEiDeXaRrYIm6pF9vwHZkOvGjuhKQ_E=.628cf54f-af74-45ca-81bd-51f99a723753@github.com>
Message-ID: <Z-TGx99-lIFcZtVy3HVXAK_YQZpx__xyJ9qKtFgSRLc=.c882e45b-1c34-49eb-b806-e1a67d74bf4a@github.com>

On Sun, 21 Aug 2022 21:10:29 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated as per review comment
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1261:
> 
>> 1259: 
>> 1260:         private static double formatToDoubleValue(long len) {
>> 1261:             return (len / 100L) / 10.0d;
> 
> First "formatToDouble" isn't really a very good name for this. 
> Perhaps I could provide a better one if I could be sure of what the intent is here but
> at the very least this method needs comments explaining what it is doing AND why.
> 
> The first (len / 100L) expression means that (eg)
> 100 and 199 will both become 1 and the return value of the method is 0.1 
> 
> So rounding DOWN is happening here, whereas (separately) we round UP for value < 100 ..
> 
> So anything from 1  byte to 199 bytes will be 0.1 KB ?
> 
> The test doesn't seem to cover this case.

"formatToDouble" method is taking filesize as a long value in parameter and convert it to one decimal precision value. 
The reason for converting to one decimal point is to make it similar to native file system which shows file size in one decimal precision.

can "formatToDouble" method rename to "getOneDecimalPrecisionFileSize" ?

Since we are displaying file size in one decimal precision, files having size from 1 to 199 byte will be 0.1 KB. 
1 to 99 byte file size is handled separately otherwise it will show 0.0 KB.

I will add few test case for 100 to 199 byte file.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Mon Aug 22 11:15:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 22 Aug 2022 11:15:46 GMT
Subject: RFR: 8267374: macOS: Option+Up/Down Arrow don't traverse to
 beginning/end of line in JTextArea [v9]
In-Reply-To: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
References: <U5NHuMp24vnZFqYYMrRu1vxewinKWd-IkEhP10IHsi4=.d7b8d997-b2c1-43a1-afb4-e11597ec65ff@github.com>
Message-ID: <06GveC0MUWKxfgCAQt3YpxVCSbE6s_Jp7eegLjeXy3E=.80471a1e-79fd-4e64-b16e-72f4a0f1bc2f@github.com>

> Unlike in native "Notes" editor where Option+Up/Down traverses to start/end of each line respectively,
> Java does not honour these key combination in editor.
> 
> Added the key combination support by moving the caret to start/end of line and then doing caret up/down a line depending on if we are pressing UP or DOWN key.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Restrict one more test for ALTGraph

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9230/files
  - new: https://git.openjdk.org/jdk/pull/9230/files/392b415a..78df4a71

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9230&range=07-08

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9230.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9230/head:pull/9230

PR: https://git.openjdk.org/jdk/pull/9230


From psadhukhan at openjdk.org  Mon Aug 22 11:17:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 22 Aug 2022 11:17:34 GMT
Subject: Integrated: 6445283: ProgressMonitorInputStream not large file aware
 (>2GB)
In-Reply-To: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
References: <1AVL6WCeaKUUrOMrP1nfql2Ifxo7CymYj3OyMUyaH5s=.d104ee28-cb9d-4b42-8453-d4454d652420@github.com>
Message-ID: <u1Lz1koYbsWqlFsxHH6hc9sLsXGLaG74B8gpW_75jdw=.192ce1a2-9095-4566-87c7-8a165bd4bbed@github.com>

On Thu, 21 Jul 2022 10:47:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> If ProgressMonitor has to show progress for reading file > 2GB, it goes to 100% and then again start from 0. 
> This is because
> it uses "int" to store bytes read (`nread`) and when it reads data from file, it adds 
> "number-bytes-to-read "nr" to number-bytes-already-read "nread" variable [`nread += nr`] which can cause it to overflow and so "nread" becomes -ve.
> 
> Fix is to check if adding bytes-to-read to number-bytes-already-read will exceed MAX_INT, then set Progress to max so that ProgressMonitor can close the tracker 
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/ProgressMonitor.java#L265
> 
> No regression test is added as it involves using filesize of >2GB.

This pull request has now been integrated.

Changeset: a17fce75
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a17fce7507c7d485d51f98fadd444235ea31058d
Stats:     134 lines in 2 files changed: 118 ins; 12 del; 4 mod

6445283: ProgressMonitorInputStream not large file aware (>2GB)

Reviewed-by: azvegint, prr

-------------

PR: https://git.openjdk.org/jdk/pull/9588


From psadhukhan at openjdk.org  Mon Aug 22 11:37:01 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 22 Aug 2022 11:37:01 GMT
Subject: RFR: JDK-8292715: Cleanup Problemlist
Message-ID: <vcp-zpylU9cS1Eq66cSnTLSGo5cuzzfUdzLrGlVx880=.b5e40ddb-b793-4353-84fb-d77a9a88c04b@github.com>

Cleanup of Problemlist

-------------

Commit messages:
 - JDK-8292715: Cleanup Problemlist

Changes: https://git.openjdk.org/jdk/pull/9963/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292715
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9963.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9963/head:pull/9963

PR: https://git.openjdk.org/jdk/pull/9963


From jwaters at openjdk.org  Mon Aug 22 11:40:28 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 22 Aug 2022 11:40:28 GMT
Subject: RFR: 8292314: Cleanup legacy address handling [v3]
In-Reply-To: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
References: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
Message-ID: <df33Iw3sXocZWQvgk-CR5GFj7x4auJFt6X0HR8yCRvU=.9b84e513-0502-47f6-8b2e-224c538d20cf@github.com>

> Cleanup legacy address check in libsplashscreen obsoleted by http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/75755e92430c

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-6
 - Merge branch 'openjdk:master' into patch-6
 - First try, remove memory address entirely

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9866/files
  - new: https://git.openjdk.org/jdk/pull/9866/files/3e7830d7..3082cae2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9866&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9866&range=01-02

  Stats: 4057 lines in 225 files changed: 1909 ins; 1071 del; 1077 mod
  Patch: https://git.openjdk.org/jdk/pull/9866.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9866/head:pull/9866

PR: https://git.openjdk.org/jdk/pull/9866


From aivanov at openjdk.org  Mon Aug 22 15:24:35 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Aug 2022 15:24:35 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v8]
In-Reply-To: <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
 <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>
Message-ID: <jk-SHSLwtL0RYXoJmYSjPyohKtE8wTOq-TIVPDhoz8k=.5b95fb25-a665-4bcb-8755-d4b45517c236@github.com>

On Sun, 21 Aug 2022 22:00:09 GMT, Phil Race <prr at openjdk.org> wrote:

> But what if the test window is > 0.5 the width of the screen ? Now it is off the edge .. wouldn't it be better to move the instruction window to the left to accommodate it ?

It would be better. The same problem exists for vertical and horizontal positioning: if the test window is larger than half the width of the screen, its part may become off the edge.

Should this be dealt with in a separate issue?

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From aivanov at openjdk.org  Mon Aug 22 15:35:47 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Aug 2022 15:35:47 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <37PLBrSt3h8f3b0vxFRl4HwHpKwCkWaymy-sHGMMgic=.2d56b930-8377-45e1-8264-a83a55789cd5@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
 <Mob16bWMjoymF5RoSMaTCfGWk6qc4gdKCzNX6U1enr0=.a33baf4e-b0ad-44ac-95fa-b283026f7850@github.com>
 <37PLBrSt3h8f3b0vxFRl4HwHpKwCkWaymy-sHGMMgic=.2d56b930-8377-45e1-8264-a83a55789cd5@github.com>
Message-ID: <0L_5nT7vcXiJdTIiF_ve5LuWyIZr7CSTkZ22nM7vIDs=.38dce724-3867-4d5f-820e-d45d98297760@github.com>

On Wed, 17 Aug 2022 04:25:26 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

> } else if (len < 1024L) { ... } has been removed in previous commit. So if listViewWindowsStyle is false then the next else if will be executed i.e. <100L.

For clarity, would it be better to separate the cases?


                if (listViewWindowsStyle) {
                    if (len == 0) {
                } else {
                    if (len < 100L) {
                }


This would increase the indentation level, yet it would make the code clearer. Now two independent conditions are chained.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Mon Aug 22 17:13:26 2022
From: duke at openjdk.org (Martin Desruisseaux)
Date: Mon, 22 Aug 2022 17:13:26 GMT
Subject: RFR: 8290973: In AffineTransform,
 equals(Object) is inconsistent with hashCode() [v2]
In-Reply-To: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
References: <rgO_f_XZieJb7h4Vwe26YnCgcWoVcarEW18_tfZgPzs=.e56a4940-8e87-4ba3-9ffd-edd9c91ca107@github.com>
Message-ID: <ct_RNqaFw2LBdH6FJWYUuAgW9I2aZIoUQ0mg_GY3ZPU=.901a3dd2-b1b1-4d87-970d-5aa6c70a96e4@github.com>

> `AffineTransform.equals(Object)` and `hashCode()` break two contracts:
> 
> * `A.equals(A)` returns `false` if at least one affine transform coefficient is NaN.
> * `A.equals(B)` should imply `A.hashCode() == B.hashCode()`, but it is not the case if a coefficient is zero with an opposite sign in A and B.
> 
> This patch preserves the current behaviour regarding 0 (i.e. -0 is considered equal to +0) for backward compatibility reason. Instead the `hashCode()` method is updated for being consistent with `equals(Object)` behaviour.

Martin Desruisseaux has updated the pull request incrementally with one additional commit since the last revision:

  Fix a trivial typo: "into to" -> "to".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9121/files
  - new: https://git.openjdk.org/jdk/pull/9121/files/12abfde7..8ee3f7b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9121&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9121&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9121.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9121/head:pull/9121

PR: https://git.openjdk.org/jdk/pull/9121


From honkar at openjdk.org  Mon Aug 22 18:05:41 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 18:05:41 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v9]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <it5Kma4zsKwbYstmEWKJ_ig36OaL5pFBE3QcfCn2FUk=.f2a8fe76-34c3-44a4-a740-d0bdfdaa6d88@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

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 ten additional commits since the last revision:

 - Merge branch 'master' into ManualTestsGH_8289075
 - review changes
 - helper method added to sync location
 - added null check in positionWindow
 - added Thread.sleep and changed the location of setVisible
 - added screen insets to account for taskbar position, doc changes
 - window positioning changes
 - Top left positon added
 - PassFailJFrame changes for multiple frame scenarios

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/0567db94..9678450a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=07-08

  Stats: 76050 lines in 1646 files changed: 38587 ins; 30132 del; 7331 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Mon Aug 22 19:35:34 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 19:35:34 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v10]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  javadoc update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/9678450a..7d4f4c86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=08-09

  Stats: 13 lines in 1 file changed: 2 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Mon Aug 22 19:35:36 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 19:35:36 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v8]
In-Reply-To: <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
 <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>
Message-ID: <t2P05M4jD1DUd-oWrngeseRL8qwG_g8HvSbAmIxzygs=.481b23fe-bbbf-43c3-b27f-1d6ec53d13a7@github.com>

On Sun, 21 Aug 2022 22:00:09 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review changes
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 278:
> 
>> 276:      *                  center and the test window (if not null) is placed to
>> 277:      *                  the right of the instruction frame.
>> 278:      *
> 
> "vertical center" means half way between the top and the bottom which is absolutely not what you mean, is it ?
> 
> horizontal center surely ?
> 
> But what if the test window is > 0.5 the width of the screen ? Now it is off the edge .. wouldn't it be better
> to move the instruction window to the left to accommodate it ?
> Although that might be tricky if we don't know its size yet ..

@prrace @aivanov-jdk For Horizontal position, the frame and window are positioned as follows - 

![image](https://user-images.githubusercontent.com/95945681/185998431-93adcced-cef9-4c04-bd2a-4511b6f34210.png). 

I intended to convey that the right edge of the instruction frame aligns with the yellow line, the line that runs vertically and divides the screen into right and left halves (vertical center - probably not the right term, as Phil mentioned horizontal center might be correct word here. Updated it in the latest commit.


> But what if the test window is > 0.5 the width of the screen ? Now it is off the edge .. wouldn't it be better
> to move the instruction window to the left to accommodate it ?
> Although that might be tricky if we don't know its size yet ..

Yes I agree, can we take it up as a separate issue while redesigning the framework as @aivanov-jdk suggested?

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Mon Aug 22 19:48:43 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 19:48:43 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v8]
In-Reply-To: <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
 <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>
Message-ID: <jBsWYE0kJ_xyNH6wYKRbeorzFPzLoZxL1lUwAckYThI=.955fbb58-07eb-48d9-af84-f3f6c24374a8@github.com>

On Sun, 21 Aug 2022 21:52:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review changes
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 269:
> 
>> 267:      * parameter.
>> 268:      * Note: This method should be invoked from the method that creates
>> 269:      * testWindow. At test-level, the testWindow must be made visible
> 
> I think we should remove that Note sentence - surely the calling method is irrelevant. 
>  It is sufficient to explain that 
> "This method should be called before making the test window visible".
> But why is that ?

@prrace If the testWindow is made visible before calling `positionTestWindow()`, it is seen in the previous location for a short duration before being moved to the final location. Visually, the swap from previous to new location was visible. To avoid this, `testWindow.setVisible()` needs to called after `positionTestWindow()`. https://github.com/openjdk/jdk/pull/9525#issuecomment-1205915695

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From aivanov at openjdk.org  Mon Aug 22 19:57:54 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Aug 2022 19:57:54 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v22]
In-Reply-To: <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
Message-ID: <vGGX3jfHiNVf781TbkpEGBvXTIbteGivaQytFsTIufI=.bf9c6f3b-939b-4566-9fcc-b19536d3235f@github.com>

On Fri, 19 Aug 2022 10:40:14 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per review comment

src/java.desktop/share/classes/sun/swing/FilePane.java line 1187:

> 1185:             // TODO: it's rather a temporary trick, to be revised
> 1186:             String text;
> 1187:             Object[] objs = new Object[1];

I suggest moving this declaration into the following block:


            } else if (value instanceof Long len) {
                Object[] objs = new Object[1];

                if (listViewWindowsStyle) {


This will reduce the visibility of the variable to the block where it's used.

Giving it a descriptive name would also be better. Is `fileSize` good enough? `displayedFileSize`?

src/java.desktop/share/classes/sun/swing/FilePane.java line 1205:

> 1203:                  * similar to linux file system
> 1204:                  * Empty file size show as 0.0 KB
> 1205:                  * 1->100 byte files show as 0.1 KB and so on

Suggestion:

                 * Code block is relevant to Linux.
                 * File size is display up to 1 decimal precision.
                 * Base-10 number system used for formatting file size
                 * similar to how it's formatted in file managers on Linux.
                 * Empty file size is shown as 0.0 KB,
                 * 1-100-byte files are shown as 0.1 KB and so on.

test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 65:

> 63:         JFrame frame = new JFrame("JFileChooser File Size test");
> 64:         JFileChooser fc = new JFileChooser();
> 65:         Path dir = Paths.get(System.getProperty("test.src"));

When run with jtreg, it creates the files in the test source tree, which is probably not what we want. If the files aren't removed, they'll be left in the source tree and may prevent further updates to the source.

Should this always default to the current directory? When `jtreg` runs a test, the current directory is a `scratch` directory which is cleaned between the tests if the test passes, if the test fails, the contents is copied to the test log directory.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Mon Aug 22 20:46:39 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Aug 2022 20:46:39 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <cdRzm-sk68j0WgIWw2W8x7lQ_6Srmhlyo-h2BD7Dvfo=.931e46c3-8ec4-4efc-9e14-3878ec6dbf34@github.com>

On Fri, 19 Aug 2022 23:47:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true all platforms when frame.pack() is called.

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1413:

> 1411:     if (m_insets.left < 0 || m_insets.top < 0 ||
> 1412:         m_insets.right < 0 || m_insets.bottom < 0 ||
> 1413:         JNU_IsInstanceOfByName(env, target, "java/awt/Frame") > 0) {

Does it mean that now we will always request the insets from the platform?

Was this code run before the frame was changed from resizeable to non-resizeable? Therefore the insets weren't updated correctly.

Is this applicable to windows?

test/jdk/java/awt/Frame/AwtFramePackTest.java line 101:

> 99:                 System.out.println("Actual frame size: " + actualFrameSize);
> 100:                 saveScreenCapture(frameType + ".png");
> 101:                 errorLog.append(frameType + ": Expected and Actual frame size" +

`frameType` is used only inside this failure block, so it's declaration can be moved here before it's used for the first time.

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From honkar at openjdk.org  Mon Aug 22 21:16:35 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 21:16:35 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <cdRzm-sk68j0WgIWw2W8x7lQ_6Srmhlyo-h2BD7Dvfo=.931e46c3-8ec4-4efc-9e14-3878ec6dbf34@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <cdRzm-sk68j0WgIWw2W8x7lQ_6Srmhlyo-h2BD7Dvfo=.931e46c3-8ec4-4efc-9e14-3878ec6dbf34@github.com>
Message-ID: <xoXoBIymERTNe4aeom-6qlkjqZj7xZxDyV9nD_geBnE=.6b0d75f8-f3b3-4354-978c-acfcc388b33b@github.com>

On Mon, 22 Aug 2022 20:38:30 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does it mean that now we will always request the insets from the platform?

**_Yes the following block of code runs when window isn't sized yet (first time) or when the incoming taget is a frame to obtain platform insets_**

> Was this code run before the frame was changed from resizeable to non-resizeable? Therefore the insets weren't updated correctly.

 _**It was not going into this block for resizable frames. The issue was with the cached insets. The first time when frame,pack() is called on non-resizable frame the correct insets associated with it is returned and the frame is sized accordingly. But any subsequent calls to frame.getInsets() or frame.getPreferredSize() which gets the cached insets from [WPanelPeer](https://github.com/openjdk/jdk/blob/27af0144ea57e86d9b81c2b328fad66e4a046f61/src/java.desktop/windows/classes/sun/awt/windows/WPanelPeer.java#L62) was returning the cached insets of Resizable frame and not that of the Non-Resizable frame**_

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From duke at openjdk.org  Mon Aug 22 21:21:31 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 22 Aug 2022 21:21:31 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v6]
In-Reply-To: <nVCzpDMzdY4CIXSx27BsR53YexilKhIyiKF3f_ticDw=.bfb3f7c1-cd41-43ec-9eda-2f807dad5e5a@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <x2YkLZxgXHqVe6EdebqiIfQQynJxBYC7PuQM0U11YFg=.d703dec2-14b6-499d-8a32-20aac151b8ea@github.com>
 <nVCzpDMzdY4CIXSx27BsR53YexilKhIyiKF3f_ticDw=.bfb3f7c1-cd41-43ec-9eda-2f807dad5e5a@github.com>
Message-ID: <MAJFbAsoxn4gGNqR2IwhOhiI8V9VEb4MFXd6LRfAUOg=.21f70393-6853-4a5d-9cc0-9dc6ae504800@github.com>

On Mon, 22 Aug 2022 00:57:28 GMT, SWinxy <duke at openjdk.org> wrote:

>> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removes whitespace.
>>   
>>   Remove a whitespace at the end of the file
>
> I mean I think I would *prefer* the switch over a map (it looks nicer to me). My crude tests showed that the switch is indeed slower, breaking my conception that switch statements are the peak of performance. Other than [this request](#issuecomment-1216011827), I have no further comments.

@SWinxy Thanks for your reviews and confirmation tests.
Do you notice that the `switch ... case` is also two times slower than my "handmade" binary tree using `if ... else` !  A problem in the implementation of  'switch ... case' ?

-------------

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Mon Aug 22 21:28:09 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 22 Aug 2022 21:28:09 GMT
Subject: RFR: 8292738 : JInternalFrame backgroundShadowBorder &
 foregroundShadowBorder line is longer in Mac Look and Feel
Message-ID: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>

Border line is seen outside  round Rectangle both for JInternalFrame backgroundShadowBorder & foregroundShadowBorder line in mac L&F.
![Screen Shot 2022-08-22 at 4 17 49 PM](https://user-images.githubusercontent.com/87324768/186021010-d21aed21-9e05-4b28-846b-2628e367f183.png)

I have circled the extra part of the line. To make it more visible I changed the color of the backgroundShadowBorder to red
![Screen Shot 2022-08-22 at 4 17 37 PM](https://user-images.githubusercontent.com/87324768/186021095-cbfffdba-d43a-47e7-a50b-551c59cb767b.png)

Fixed the extra length of the line 
![Fixed](https://user-images.githubusercontent.com/87324768/186021195-688c3613-fc50-41c3-8cad-94173385dfeb.png)

-------------

Commit messages:
 - 8292738 : JInternalFrame backgroundShadowBorder & foregroundShadowBorder line is longer in Mac Look and Feel

Changes: https://git.openjdk.org/jdk/pull/9971/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292738
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9971.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9971/head:pull/9971

PR: https://git.openjdk.org/jdk/pull/9971


From duke at openjdk.org  Mon Aug 22 21:45:36 2022
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 22 Aug 2022 21:45:36 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v10]
In-Reply-To: <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>
Message-ID: <Uf5seJm7_wy9UkpBduYXPrONUiLAmelUHObaglmp1wc=.09956b8f-e95b-405d-858b-411103a61bf6@github.com>

On Mon, 22 Aug 2022 19:35:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

Adding a button 'Screen capture' ( Screen shot ) in test instruction frame when user clicks to fail button to capture the failure scenario will be good idea. Screen shot to capture both test instruction frame as well as Test frame. This will help every one to know the following
1) Test scenario that user is testing
2) What exactly user is seeing on the screen ( test frame ) along with failure reason that user is entering now.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From aivanov at openjdk.org  Mon Aug 22 21:59:27 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Aug 2022 21:59:27 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <xoXoBIymERTNe4aeom-6qlkjqZj7xZxDyV9nD_geBnE=.6b0d75f8-f3b3-4354-978c-acfcc388b33b@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <cdRzm-sk68j0WgIWw2W8x7lQ_6Srmhlyo-h2BD7Dvfo=.931e46c3-8ec4-4efc-9e14-3878ec6dbf34@github.com>
 <xoXoBIymERTNe4aeom-6qlkjqZj7xZxDyV9nD_geBnE=.6b0d75f8-f3b3-4354-978c-acfcc388b33b@github.com>
Message-ID: <MjNE1aU3pyeifNsMVvPPZg-UhRyQYDC0YKetR2CAKcQ=.60fcd97a-69d9-46b3-a8bf-130c3534a089@github.com>

On Mon, 22 Aug 2022 21:12:58 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1413:
>> 
>>> 1411:     if (m_insets.left < 0 || m_insets.top < 0 ||
>>> 1412:         m_insets.right < 0 || m_insets.bottom < 0 ||
>>> 1413:         JNU_IsInstanceOfByName(env, target, "java/awt/Frame") > 0) {
>> 
>> Does it mean that now we will always request the insets from the platform?
>> 
>> Was this code run before the frame was changed from resizeable to non-resizeable? Therefore the insets weren't updated correctly.
>> 
>> Is this applicable to windows?
>
>> Does it mean that now we will always request the insets from the platform?
> 
> **_Yes the following block of code runs when window isn't sized yet (first time) or when the incoming taget is a frame to obtain platform insets_**
> 
>> Was this code run before the frame was changed from resizeable to non-resizeable? Therefore the insets weren't updated correctly.
> 
>  _**It was not going into this block for resizable frames. The issue was with the cached insets. The first time when frame,pack() is called on non-resizable frame the correct insets associated with it is returned and the frame is sized accordingly. But any subsequent calls to frame.getInsets() or frame.getPreferredSize() which gets the cached insets from [WPanelPeer](https://github.com/openjdk/jdk/blob/27af0144ea57e86d9b81c2b328fad66e4a046f61/src/java.desktop/windows/classes/sun/awt/windows/WPanelPeer.java#L62) was returning the cached insets of Resizable frame and not that of the Non-Resizable frame**_

And this is unclear to me. The frame is set to non-resizeable, `frame.pack()` is called. This, I assume, results in this code block being executed, so the calculated insets should be cached.

Why do the following calls to `getInsets` or `getPreferredSize` return the *resizeable* insets if the cached ones are *non-resizeable*?

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From aivanov at openjdk.org  Mon Aug 22 21:59:28 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Aug 2022 21:59:28 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <MjNE1aU3pyeifNsMVvPPZg-UhRyQYDC0YKetR2CAKcQ=.60fcd97a-69d9-46b3-a8bf-130c3534a089@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <cdRzm-sk68j0WgIWw2W8x7lQ_6Srmhlyo-h2BD7Dvfo=.931e46c3-8ec4-4efc-9e14-3878ec6dbf34@github.com>
 <xoXoBIymERTNe4aeom-6qlkjqZj7xZxDyV9nD_geBnE=.6b0d75f8-f3b3-4354-978c-acfcc388b33b@github.com>
 <MjNE1aU3pyeifNsMVvPPZg-UhRyQYDC0YKetR2CAKcQ=.60fcd97a-69d9-46b3-a8bf-130c3534a089@github.com>
Message-ID: <_Fu286WNCl5BafCscQ293DwCjpJ0C4SnXMkUHjLZvyY=.6c3abdca-9331-4974-99af-e6dc50baa1c4@github.com>

On Mon, 22 Aug 2022 21:52:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Does it mean that now we will always request the insets from the platform?
>> 
>> **_Yes the following block of code runs when window isn't sized yet (first time) or when the incoming taget is a frame to obtain platform insets_**
>> 
>>> Was this code run before the frame was changed from resizeable to non-resizeable? Therefore the insets weren't updated correctly.
>> 
>>  _**It was not going into this block for resizable frames. The issue was with the cached insets. The first time when frame,pack() is called on non-resizable frame the correct insets associated with it is returned and the frame is sized accordingly. But any subsequent calls to frame.getInsets() or frame.getPreferredSize() which gets the cached insets from [WPanelPeer](https://github.com/openjdk/jdk/blob/27af0144ea57e86d9b81c2b328fad66e4a046f61/src/java.desktop/windows/classes/sun/awt/windows/WPanelPeer.java#L62) was returning the cached insets of Resizable frame and not that of the Non-Resizable frame**_
>
> And this is unclear to me. The frame is set to non-resizeable, `frame.pack()` is called. This, I assume, results in this code block being executed, so the calculated insets should be cached.
> 
> Why do the following calls to `getInsets` or `getPreferredSize` return the *resizeable* insets if the cached ones are *non-resizeable*?

> Is this applicable to windows?

I mean to `Window` objects.

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From prr at openjdk.org  Mon Aug 22 21:59:33 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 Aug 2022 21:59:33 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v10]
In-Reply-To: <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>
Message-ID: <qFnX75a5ZSFYBMHtfFFF5Kv4GyS5KgJOxSqsG_33sJ0=.7e2151e5-8986-48f8-ac7e-0cde6dd91f6f@github.com>

On Mon, 22 Aug 2022 19:35:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc update

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From prr at openjdk.org  Mon Aug 22 21:59:34 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 Aug 2022 21:59:34 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v10]
In-Reply-To: <Uf5seJm7_wy9UkpBduYXPrONUiLAmelUHObaglmp1wc=.09956b8f-e95b-405d-858b-411103a61bf6@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>
 <Uf5seJm7_wy9UkpBduYXPrONUiLAmelUHObaglmp1wc=.09956b8f-e95b-405d-858b-411103a61bf6@github.com>
Message-ID: <8HyMT349gZP-Q2Ar8bKgrfi6OLKy71OqwbqAJtDdVmM=.2b0f1be7-6e9c-43e2-a760-b34b3648e185@github.com>

On Mon, 22 Aug 2022 21:42:11 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Adding a button 'Screen capture' ( Screen shot ) in test instruction frame when user clicks to fail button to capture the failure scenario will be good idea. Screen shot to capture both test instruction frame as well as Test frame. This will help every one to know the following
> 
> 1. Test scenario that user is testing
> 2. What exactly user is seeing on the screen ( test frame ) along with failure reason that user is entering now.

Another thing do later in a follow on RFE. It is a stretch to add that to a fix that adds a new positioning option.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From prr at openjdk.org  Mon Aug 22 21:59:36 2022
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 Aug 2022 21:59:36 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v8]
In-Reply-To: <t2P05M4jD1DUd-oWrngeseRL8qwG_g8HvSbAmIxzygs=.481b23fe-bbbf-43c3-b27f-1d6ec53d13a7@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <bj1slqc94wGFP-oQVl_ERglXhkggA0VonxdIqahjtNY=.fd83dfba-306d-4930-b8d8-90ffcb5a56a2@github.com>
 <fTSGZ6h1ixlMnkWK4jJJn2_zHTo8tZlRIbkM2FlQVA8=.44eaadb1-1edb-4dd9-8685-f57b33a0f68b@github.com>
 <t2P05M4jD1DUd-oWrngeseRL8qwG_g8HvSbAmIxzygs=.481b23fe-bbbf-43c3-b27f-1d6ec53d13a7@github.com>
Message-ID: <GnTwDS49DngvseIqBz2EXoKkmdz7lfwgGPAlejaDTPc=.53d22105-cfa3-48cb-9707-106253d78e07@github.com>

On Mon, 22 Aug 2022 19:32:34 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 278:
>> 
>>> 276:      *                  center and the test window (if not null) is placed to
>>> 277:      *                  the right of the instruction frame.
>>> 278:      *
>> 
>> "vertical center" means half way between the top and the bottom which is absolutely not what you mean, is it ?
>> 
>> horizontal center surely ?
>> 
>> But what if the test window is > 0.5 the width of the screen ? Now it is off the edge .. wouldn't it be better
>> to move the instruction window to the left to accommodate it ?
>> Although that might be tricky if we don't know its size yet ..
>
> @prrace @aivanov-jdk For Horizontal position, the frame and window are positioned as follows - 
> 
> ![image](https://user-images.githubusercontent.com/95945681/185998431-93adcced-cef9-4c04-bd2a-4511b6f34210.png). 
> 
> I intended to convey that the right edge of the instruction frame aligns with the yellow line, the line that runs vertically and divides the screen into right and left halves (vertical center - probably not the right term, as Phil mentioned horizontal center might be correct word here. Updated it in the latest commit.
> 
> 
>> But what if the test window is > 0.5 the width of the screen ? Now it is off the edge .. wouldn't it be better
>> to move the instruction window to the left to accommodate it ?
>> Although that might be tricky if we don't know its size yet ..
> 
> Yes I agree, can we take it up as a separate issue while redesigning the framework as @aivanov-jdk suggested?
> Should be account for this in positonTestWindow() javadocs - something like - "**_approximately_** positions the testWindow and instruction frame according to {@code position} parameter."

Yes, a pre-existing issue. Dealing with it later is OK even though it'll slightly respecify the method again.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Mon Aug 22 22:32:50 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 22:32:50 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v11]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor change to positionTestWindow javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/7d4f4c86..2c72bc35

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=09-10

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Mon Aug 22 22:38:41 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 22:38:41 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v11]
In-Reply-To: <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
Message-ID: <33q0ibpU2OZY6TrWjRpW2_bM-jbNpWI34_30raZPrTk=.f223f625-2020-4ca3-9d8f-9aa2b87d83a3@github.com>

On Mon, 22 Aug 2022 22:32:50 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change to positionTestWindow javadoc

Based on this discussion https://github.com/openjdk/jdk/pull/9525#discussion_r951837454, Added the term "approximately positions" to positionTestWindow() javadoc.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Mon Aug 22 22:53:26 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 22 Aug 2022 22:53:26 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v10]
In-Reply-To: <8HyMT349gZP-Q2Ar8bKgrfi6OLKy71OqwbqAJtDdVmM=.2b0f1be7-6e9c-43e2-a760-b34b3648e185@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>
 <Uf5seJm7_wy9UkpBduYXPrONUiLAmelUHObaglmp1wc=.09956b8f-e95b-405d-858b-411103a61bf6@github.com>
 <8HyMT349gZP-Q2Ar8bKgrfi6OLKy71OqwbqAJtDdVmM=.2b0f1be7-6e9c-43e2-a760-b34b3648e185@github.com>
Message-ID: <ftwNL5tYM2sUwX-opKHl0Z7SavhvKyubzHtzVxCe2Bk=.bec044d4-b970-402d-bb58-5772e3b0cb7a@github.com>

On Mon, 22 Aug 2022 21:54:44 GMT, Phil Race <prr at openjdk.org> wrote:

> > Adding a button 'Screen capture' ( Screen shot ) in test instruction frame when user clicks to fail button to capture the failure scenario will be good idea. Screen shot to capture both test instruction frame as well as Test frame. This will help every one to know the following
> > 
> > 1. Test scenario that user is testing
> > 2. What exactly user is seeing on the screen ( test frame ) along with failure reason that user is entering now.
> 
> Another thing do later in a follow on RFE. It is a stretch to add that to a fix that adds a new positioning option.

The above suggestion was meant to be added by @lawrence-andrew as part of the test redesign discussion https://github.com/openjdk/jdk/pull/9525#issuecomment-1220057640

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From psadhukhan at openjdk.org  Tue Aug 23 04:06:16 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 23 Aug 2022 04:06:16 GMT
Subject: RFR: JDK-8292715: Cleanup Problemlist [v2]
In-Reply-To: <vcp-zpylU9cS1Eq66cSnTLSGo5cuzzfUdzLrGlVx880=.b5e40ddb-b793-4353-84fb-d77a9a88c04b@github.com>
References: <vcp-zpylU9cS1Eq66cSnTLSGo5cuzzfUdzLrGlVx880=.b5e40ddb-b793-4353-84fb-d77a9a88c04b@github.com>
Message-ID: <p6iiFOTBS62SvrkWojvB3YS73qoaNgOmpoOBgkEuDV4=.3b029dbc-79c1-446e-9765-9f63d620fb66@github.com>

> Cleanup of Problemlist

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Seggregate swing and awt manual tests as part of cleanup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9963/files
  - new: https://git.openjdk.org/jdk/pull/9963/files/f5d269e5..c5c0f6cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9963&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9963&range=00-01

  Stats: 9 lines in 1 file changed: 5 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9963.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9963/head:pull/9963

PR: https://git.openjdk.org/jdk/pull/9963


From psadhukhan at openjdk.org  Tue Aug 23 05:25:32 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 23 Aug 2022 05:25:32 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v11]
In-Reply-To: <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
Message-ID: <x5kIY_VP4KvlWIiN3mZ0lzyIGagpJO0T_RmXT2DTc_o=.5f959599-6369-435f-81e2-c08cb22852f6@github.com>

On Mon, 22 Aug 2022 22:32:50 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change to positionTestWindow javadoc

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 268:

> 266:      * is null, only the instruction frame is positioned according to
> 267:      * {@code position} parameter. This method should be called before making
> 268:      * the test window visible.

Since this condition is documented, should we also implement check to handle it by calling isShowing() and throw some warning/exception if its visible.
We do the opposite for getLocationOnScreen() where we throw exception if the compoment is not showing.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From psadhukhan at openjdk.org  Tue Aug 23 05:49:28 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 23 Aug 2022 05:49:28 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <aiGrm0biUjAb0wZAsbR2fW7bvKYjGeNoYug1MLvOk3A=.5f43448f-0636-4ddd-a73c-580381cb955f@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
 <aiGrm0biUjAb0wZAsbR2fW7bvKYjGeNoYug1MLvOk3A=.5f43448f-0636-4ddd-a73c-580381cb955f@github.com>
Message-ID: <PekUUNpC2oxcidxOrEBr-JOmBIyrANdJo0k37mDH1tU=.edd6d308-421c-4b4b-a71e-a6b885e1c71a@github.com>

On Thu, 11 Aug 2022 16:44:49 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> @andy-goryachev-oracle I took into consideration your comment regarding RTL and LTR behavior regarding JComboBoxes. I did the testing as we briefly discussed and all results led me to believe Aqua L&F combo boxes only supported the button being on the right. Will still need to check with a device natively set to RTL, but it turns out a nearly decade old JBS issue already exists for this JComboBox button issue. I'll leave that separate from this PR and possibly look into that other issue later.

Yes, [JDK-8023912](https://bugs.openjdk.org/browse/JDK-8023912)...
I am not sure if this RTL is an issue. I guess it was mentioned in our meeting that RTL should not affect JComboBox button. 
Maybe another question for apple, since the button image drawn by JRS?

-------------

PR: https://git.openjdk.org/jdk/pull/9473


From aivanov at openjdk.org  Tue Aug 23 14:39:58 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Aug 2022 14:39:58 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v11]
In-Reply-To: <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
Message-ID: <jD4wFpDommooSh4SXyRDgSK5gwX369IeLKaV0cRXPo4=.4a6ce4c9-1088-4c96-830c-7590797090f5@github.com>

On Mon, 22 Aug 2022 22:32:50 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor change to positionTestWindow javadoc

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 268:

> 266:      * is null, only the instruction frame is positioned according to
> 267:      * {@code position} parameter. This method should be called before making
> 268:      * the test window visible.

Suggestion:

     * Approximately positions the instruction frame relative to the test
     * window as specified by the {@code position} parameter. If {@code testWindow}
     * is {@code null}, only the instruction frame is positioned according to
     * {@code position} parameter.
     * <p>This method should be called before making the test window visible
     * to avoid flickering.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 270:

> 268:      * the test window visible.
> 269:      *
> 270:      * @param testWindow test window that the test is created.

Suggestion:

     * @param testWindow test window that the test created.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 287:

> 285:      *                  such that its top left corner is at the top left corner of
> 286:      *                  the screen and the test window (if not null) is placed to
> 287:      *                  the right of the instruction frame.

Such formatting looks good in the source code, yet in Javadoc (which is never created, I know) and in a tooltip in an IDE, it becomes unreadable because there are no breaks.

I propose to use a list:


     * @param position  position must be one of:
     *                  <ul>
     *                  <li>{@code HORIZONTAL} - the test instruction frame is positioned
     *                  such that its right edge aligns with screen's horizontal
     *                  center and the test window (if not {@code null}) is placed to
     *                  the right of the instruction frame.
     *
     *                  <li>{@code VERTICAL} - the test instruction frame is positioned such
     *                  that its bottom edge aligns with the screen's vertical
     *                  center and the test window (if not {@code null}) is placed below
     *                  the instruction frame.
     *
     *                  <li>{@code TOP_LEFT_CORNER} - the test instruction frame is positioned
     *                  such that its top left corner is at the top left corner of
     *                  the screen and the test window (if not {@code null}) is placed to
     *                  the right of the instruction frame.
     *                  </ul>


For consistency, with `testWindow` parameter, I put `{@code}` around `null`.

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 293:

> 291: 
> 292:         // to get the screen insets inorder to position the frame by taking into
> 293:         // account the location of taskbar/menubars on screen

Suggestion:

        // Get the screen insets in order to position the frame by taking into
        // account the location of taskbar/menubars on screen

Maybe drop _?in order?_?

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From aivanov at openjdk.org  Tue Aug 23 14:46:34 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Aug 2022 14:46:34 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v11]
In-Reply-To: <x5kIY_VP4KvlWIiN3mZ0lzyIGagpJO0T_RmXT2DTc_o=.5f959599-6369-435f-81e2-c08cb22852f6@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
 <x5kIY_VP4KvlWIiN3mZ0lzyIGagpJO0T_RmXT2DTc_o=.5f959599-6369-435f-81e2-c08cb22852f6@github.com>
Message-ID: <J7PqHmtwnUPYML1P0BPjFTMfhUzG5wgveiokuBXBKm8=.41f2c081-649a-4105-8a9a-69adfa188f21@github.com>

On Tue, 23 Aug 2022 05:21:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since this condition is documented, should we also implement check to handle it by calling isShowing() and throw some warning/exception if its visible. We do the opposite for getLocationOnScreen() where we throw exception if the compoment is not showing.

It's more like a recommendation rather than a requirement. It is to avoid flickering when the window gets displayed for a very short period of time at its default position before being moved to its final position.

The same had happened to the instruction frame before Harshitha moved `setVisible(true)`.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Tue Aug 23 18:25:03 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 23 Aug 2022 18:25:03 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v12]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <VvXQDwy0PXQ1Oe0KIOw1DSEbXKOtJWvu9l-D9iLzlFI=.2b8d64cd-e2e0-483f-989b-6300f8ada6c0@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:

 - Updated javadoc as per the review comments
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
 - Updated javadoc as per the review comments
   
   Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/2c72bc35..3a52e6d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=10-11

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From aivanov at openjdk.org  Tue Aug 23 18:50:55 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Aug 2022 18:50:55 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v12]
In-Reply-To: <VvXQDwy0PXQ1Oe0KIOw1DSEbXKOtJWvu9l-D9iLzlFI=.2b8d64cd-e2e0-483f-989b-6300f8ada6c0@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <VvXQDwy0PXQ1Oe0KIOw1DSEbXKOtJWvu9l-D9iLzlFI=.2b8d64cd-e2e0-483f-989b-6300f8ada6c0@github.com>
Message-ID: <ARsQIwR7D351QtWtuQ3fZITzwetmWBpbR_eQQfaqbA8=.4f965011-786c-4d26-8933-d1c58de3fc14@github.com>

On Tue, 23 Aug 2022 18:25:03 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated javadoc as per the review comments
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>
>  - Updated javadoc as per the review comments
>    
>    Co-authored-by: Alexey Ivanov <70774172+aivanov-jdk at users.noreply.github.com>

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 332:

> 330:     /**
> 331:      * To ensure the frame location is updated by the window manager
> 332:      * if it adjusts the frame location after {@code setLocation}

Suggestion:

     * Ensures the frame location is updated by the window manager
     * if it adjusts the frame location after {@code setLocation}


For consistent documentation where method descriptions start with a verb.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From aivanov at openjdk.org  Tue Aug 23 18:56:18 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Aug 2022 18:56:18 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v10]
In-Reply-To: <ftwNL5tYM2sUwX-opKHl0Z7SavhvKyubzHtzVxCe2Bk=.bec044d4-b970-402d-bb58-5772e3b0cb7a@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <rWlET8cr6z-OFHwk3_mPDRsBLMiHZECP-vCnTnlKpls=.b1c07f51-23fc-4aa7-8f8f-ecba1d05da5d@github.com>
 <Uf5seJm7_wy9UkpBduYXPrONUiLAmelUHObaglmp1wc=.09956b8f-e95b-405d-858b-411103a61bf6@github.com>
 <8HyMT349gZP-Q2Ar8bKgrfi6OLKy71OqwbqAJtDdVmM=.2b0f1be7-6e9c-43e2-a760-b34b3648e185@github.com>
 <ftwNL5tYM2sUwX-opKHl0Z7SavhvKyubzHtzVxCe2Bk=.bec044d4-b970-402d-bb58-5772e3b0cb7a@github.com>
Message-ID: <91n5ANdny-iBZOC4j_U4Mv_I0Gu1ZRzw9H5NVwDzEFE=.38a1eb20-61fa-45d5-88e9-190d72f2d7a9@github.com>

On Mon, 22 Aug 2022 22:49:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Adding a button 'Screen capture' ( Screen shot ) in test instruction frame when user clicks to fail button to capture the failure scenario will be good idea. Screen shot to capture both test instruction frame as well as Test frame.

Capturing the entire screen is a better option. The test may create other windows, the image of the entire screen would be more useful.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Tue Aug 23 19:24:50 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 23 Aug 2022 19:24:50 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v13]
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <70GLJc4LX0OVfYcf3msTk9dbfGB1t5BztruM8v6Etoc=.e39c40e0-87b2-4a7a-84d1-a6c05976f5ec@github.com>

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  javadoc changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9525/files
  - new: https://git.openjdk.org/jdk/pull/9525/files/3a52e6d9..2db5b8a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9525&range=11-12

  Stats: 19 lines in 1 file changed: 2 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/9525.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9525/head:pull/9525

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Tue Aug 23 19:24:51 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 23 Aug 2022 19:24:51 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v11]
In-Reply-To: <J7PqHmtwnUPYML1P0BPjFTMfhUzG5wgveiokuBXBKm8=.41f2c081-649a-4105-8a9a-69adfa188f21@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
 <x5kIY_VP4KvlWIiN3mZ0lzyIGagpJO0T_RmXT2DTc_o=.5f959599-6369-435f-81e2-c08cb22852f6@github.com>
 <J7PqHmtwnUPYML1P0BPjFTMfhUzG5wgveiokuBXBKm8=.41f2c081-649a-4105-8a9a-69adfa188f21@github.com>
Message-ID: <LTT4Sfw9EPCVnV4OOMvfC4lJAylp1tuUXRgfaoMNoLM=.257bed3a-eb25-4a0d-a44a-05ea23a5bbc0@github.com>

On Tue, 23 Aug 2022 14:44:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 268:
>> 
>>> 266:      * is null, only the instruction frame is positioned according to
>>> 267:      * {@code position} parameter. This method should be called before making
>>> 268:      * the test window visible.
>> 
>> Since this condition is documented, should we also implement check to handle it by calling isShowing() and throw some warning/exception if its visible.
>> We do the opposite for getLocationOnScreen() where we throw exception if the compoment is not showing.
>
>> Since this condition is documented, should we also implement check to handle it by calling isShowing() and throw some warning/exception if its visible. We do the opposite for getLocationOnScreen() where we throw exception if the compoment is not showing.
> 
> It's more like a recommendation rather than a requirement. It is to avoid flickering when the window gets displayed for a very short period of time at its default position before being moved to its final position.
> 
> The same had happened to the instruction frame before Harshitha moved `setVisible(true)`.

Yes, as described by @aivanov-jdk ,this was added to avoid flickering (happens when windows move from the initial to the final position).

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Tue Aug 23 19:24:51 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 23 Aug 2022 19:24:51 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v11]
In-Reply-To: <jD4wFpDommooSh4SXyRDgSK5gwX369IeLKaV0cRXPo4=.4a6ce4c9-1088-4c96-830c-7590797090f5@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <7MBLJegOSgx_yY0IkGEG-wYhNA-TMXJRGOQh3pDlTt0=.bfc63731-2de4-4bb4-b7e3-5cb212844774@github.com>
 <jD4wFpDommooSh4SXyRDgSK5gwX369IeLKaV0cRXPo4=.4a6ce4c9-1088-4c96-830c-7590797090f5@github.com>
Message-ID: <CE6dbmh9XBhYONtvnOurKS2OYobYfzBBkLV0Bjg-Dmg=.f3b3d6d9-cb68-4cc1-a494-ebb7e3361d86@github.com>

On Tue, 23 Aug 2022 14:34:08 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 to positionTestWindow javadoc
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 287:
> 
>> 285:      *                  such that its top left corner is at the top left corner of
>> 286:      *                  the screen and the test window (if not null) is placed to
>> 287:      *                  the right of the instruction frame.
> 
> Such formatting looks good in the source code, yet in Javadoc (which is never created, I know) and in a tooltip in an IDE, it becomes unreadable because there are no breaks.
> 
> I propose to use a list:
> 
> 
>      * @param position  position must be one of:
>      *                  <ul>
>      *                  <li>{@code HORIZONTAL} - the test instruction frame is positioned
>      *                  such that its right edge aligns with screen's horizontal
>      *                  center and the test window (if not {@code null}) is placed to
>      *                  the right of the instruction frame.
>      *
>      *                  <li>{@code VERTICAL} - the test instruction frame is positioned such
>      *                  that its bottom edge aligns with the screen's vertical
>      *                  center and the test window (if not {@code null}) is placed below
>      *                  the instruction frame.
>      *
>      *                  <li>{@code TOP_LEFT_CORNER} - the test instruction frame is positioned
>      *                  such that its top left corner is at the top left corner of
>      *                  the screen and the test window (if not {@code null}) is placed to
>      *                  the right of the instruction frame.
>      *                  </ul>
> 
> 
> For consistency with the `testWindow` parameter, I put `{@code}` around `null`.

Updated the javadoc as per review comments.

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From aivanov at openjdk.org  Tue Aug 23 19:27:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Aug 2022 19:27:19 GMT
Subject: RFR: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework [v13]
In-Reply-To: <70GLJc4LX0OVfYcf3msTk9dbfGB1t5BztruM8v6Etoc=.e39c40e0-87b2-4a7a-84d1-a6c05976f5ec@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
 <70GLJc4LX0OVfYcf3msTk9dbfGB1t5BztruM8v6Etoc=.e39c40e0-87b2-4a7a-84d1-a6c05976f5ec@github.com>
Message-ID: <2EHi5nzOGQ7gqaedMpsP9F4CEkrvs1kh98TgezAoveY=.bdf70bd3-3cbf-40c6-a126-a9ee8f3bf60b@github.com>

On Tue, 23 Aug 2022 19:24:50 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
>> 
>> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
>> 
>> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   javadoc changes

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From honkar at openjdk.org  Tue Aug 23 21:44:24 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 23 Aug 2022 21:44:24 GMT
Subject: RFR: 8292738 : JInternalFrame backgroundShadowBorder &
 foregroundShadowBorder line is longer in Mac Look and Feel
In-Reply-To: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
References: <X5vBs9CaLJoEiIfONbCx0cwTdHuGIC5mrcEP30AOE48=.f605d66a-e387-4d5f-ba42-a7102f00939f@github.com>
Message-ID: <ToKCQou5EQSLogh_U3RdQ_fba4wGYHAS2JA43-Psne4=.fb927b21-7049-48f3-aba9-b377b0d9017b@github.com>

On Mon, 22 Aug 2022 21:20:54 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Border line is seen outside  round Rectangle both for JInternalFrame backgroundShadowBorder & foregroundShadowBorder line in mac L&F.
> ![Screen Shot 2022-08-22 at 4 17 49 PM](https://user-images.githubusercontent.com/87324768/186021010-d21aed21-9e05-4b28-846b-2628e367f183.png)
> 
> I have circled the extra part of the line. To make it more visible I changed the color of the backgroundShadowBorder to red
> ![Screen Shot 2022-08-22 at 4 17 37 PM](https://user-images.githubusercontent.com/87324768/186021095-cbfffdba-d43a-47e7-a50b-551c59cb767b.png)
> 
> Fixed the extra length of the line 
> ![Fixed](https://user-images.githubusercontent.com/87324768/186021195-688c3613-fc50-41c3-8cad-94173385dfeb.png)

Tested on SwingSet2. The overhang is not prominent unless the color of the line is changed (to test & check the difference).
Overall the fix looks good. The only question might be - Is overhang the desired appearance in Aqua LAF?

-------------

PR: https://git.openjdk.org/jdk/pull/9971


From prr at openjdk.org  Tue Aug 23 22:24:31 2022
From: prr at openjdk.org (Phil Race)
Date: Tue, 23 Aug 2022 22:24:31 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
Message-ID: <7G-JlKV_geKWK_AWgsJuh9f5roNYj7e4l07NxXDdo2o=.d86a96e6-0a0d-4003-b7a7-00ac6aa73bc3@github.com>

On Wed, 17 Aug 2022 11:48:21 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

Although I've reviewed the CSR I'd prefer it not be finalized yet. I think it needs more changes.
The spec is SILENT about what then happens if length is negative and SILENT about an out of range offset too.
I think we should address these issues as well.

Also everywhere - in the CSR and the bug description and summary the text said  the method is called setCharacterAttribute
whereas it is setCharacterAttributes.

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From honkar at openjdk.org  Wed Aug 24 00:06:36 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 24 Aug 2022 00:06:36 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
In-Reply-To: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
Message-ID: <mgMYWtlPpdOChdzGSGDka3MT99NAERAigdxZhJwJruk=.b2128a26-d95c-4459-a5b4-ffe41398f5a5@github.com>

On Wed, 17 Aug 2022 10:46:07 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Label.foreground UIProperty is not honored by Nimbus L&F.
> Added support for setting JLabel foreground color for Nimbus L&F

Copyright year for SynthLabelUI.java needs to be updated.
Applied the patch and tested, fix works.

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 77:

> 75:                                             java.awt.Color.red);
> 76:                 label =
> 77:                     new JLabel("<html><body>Can You Read This?</body></html>");

Minor suggestion:  how does "This text should be in red" sound ?

test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 119:

> 117:         }
> 118:     }
> 119: }

missing new line at EOF

-------------

PR: https://git.openjdk.org/jdk/pull/9900


From psadhukhan at openjdk.org  Wed Aug 24 04:21:26 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 24 Aug 2022 04:21:26 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
Message-ID: <-21DskiK73HbWK0fvkx1WKzGv9hDLuUM7vCMgMDDpG4=.c7df46c6-9f62-45ed-a8f2-d8f309924015@github.com>

> SplitPaneDivider.draggingColor UIProperty was not honoured in Nimbus L&F. 
> Added support for setting SplitPane dragging color for Nimbus L&F by drawing a fillRect of the set color as done in BasicLookAndFeel.
> The fix relies on `continuousLayout` property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
> 
> closed test mentioned in JBS is used for fix check.
> All jtreg swing tests are ok along with SwingSet2 JSplitPane demo in Nimbus L&F.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Revert default value

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9937/files
  - new: https://git.openjdk.org/jdk/pull/9937/files/95612ebe..1dafa3d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9937&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9937&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9937.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9937/head:pull/9937

PR: https://git.openjdk.org/jdk/pull/9937


From psadhukhan at openjdk.org  Wed Aug 24 04:31:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 24 Aug 2022 04:31:34 GMT
Subject: RFR: 7175397: The divider color is not changed to green when
 dragging for Nimbus LaF. [v2]
In-Reply-To: <zvGXKqyGaF5qOr_kI7qIs8bwCdb0aF4G2oeQgV4l2nk=.37b7ffe6-4eaf-4211-bdb9-bd3427eaf6f2@github.com>
References: <GzrBfoOoTf_RXa-8JXIrh1gA0SJC-D5XemF5RN73QbU=.b3a38ff7-f47a-479a-8709-3da0b5d78009@github.com>
 <zvGXKqyGaF5qOr_kI7qIs8bwCdb0aF4G2oeQgV4l2nk=.37b7ffe6-4eaf-4211-bdb9-bd3427eaf6f2@github.com>
Message-ID: <JuaEfUn5nT-AuMrhS2FgRJhRBSRoP5R-qienGRwkUek=.ff9054fd-87af-4591-a380-c63a8fda2691@github.com>

On Sun, 21 Aug 2022 21:22:33 GMT, Phil Race <prr at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert default value
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 21333:
> 
> 
> You wrote
> 
> The fix relies on continuousLayout property being false by default which is enabled for Nimbus, which is set to default false now, same as in other L&F. I think it was set true just to have documented default value in JDK-6937415
> 
> 
> I don't think so .. it was documenting the Nimbus default which is continuous.
> Per the javadoc for 
> https://docs.oracle.com/en/java/javase/17/docs/api/java.desktop/javax/swing/JSplitPane.html#setContinuousLayout(boolean)
> 
> " The default value of this property is look and feel dependent."
> 
> So if Nimbus has had it ON all this time, it is not right to change it.

Although I am not sure why it was defaulted true for Nimbus only, but I accept that if the default value is ON all this time, we should not change it.
Modified PR to revert the default value to show the dragging color in non-continuousLayout mode as done in the closed test.

-------------

PR: https://git.openjdk.org/jdk/pull/9937


From psadhukhan at openjdk.org  Wed Aug 24 04:43:50 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 24 Aug 2022 04:43:50 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
Message-ID: <VIoRxdYnxXyLcWgaeR8nIXS4OH2KU86KDTLIK6V7cv8=.a425eff7-976f-4e8d-8e01-80a9ebdf06c6@github.com>

> Label.foreground UIProperty is not honored by Nimbus L&F.
> Added support for setting JLabel foreground color for Nimbus L&F

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9900/files
  - new: https://git.openjdk.org/jdk/pull/9900/files/788c3fd7..e6de6d08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9900&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/9900.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9900/head:pull/9900

PR: https://git.openjdk.org/jdk/pull/9900


From psadhukhan at openjdk.org  Wed Aug 24 04:43:50 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 24 Aug 2022 04:43:50 GMT
Subject: RFR: 7175396: The text on label is not painted red for Nimbus LaF.
 [v2]
In-Reply-To: <mgMYWtlPpdOChdzGSGDka3MT99NAERAigdxZhJwJruk=.b2128a26-d95c-4459-a5b4-ffe41398f5a5@github.com>
References: <sb-2w1A5kC6UHl6qTgdlP3BK2HNNJUTaDEsI8bh3Ubc=.961c0dbf-5873-4456-813a-09e13c451fbf@github.com>
 <mgMYWtlPpdOChdzGSGDka3MT99NAERAigdxZhJwJruk=.b2128a26-d95c-4459-a5b4-ffe41398f5a5@github.com>
Message-ID: <9XPek_dirBmi8Xxeauu7VZ9yka64dg3uA6DhNRTRwAo=.047ea897-c7d9-4547-8998-2434b77b5be3@github.com>

On Tue, 23 Aug 2022 23:59:23 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/javax/swing/plaf/nimbus/TestNimbusLabel.java line 77:
> 
>> 75:                                             java.awt.Color.red);
>> 76:                 label =
>> 77:                     new JLabel("<html><body>Can You Read This?</body></html>");
> 
> Minor suggestion:  how does "This text should be in red" sound ?

ok

-------------

PR: https://git.openjdk.org/jdk/pull/9900


From tr at openjdk.org  Wed Aug 24 05:51:28 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 24 Aug 2022 05:51:28 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <7G-JlKV_geKWK_AWgsJuh9f5roNYj7e4l07NxXDdo2o=.d86a96e6-0a0d-4003-b7a7-00ac6aa73bc3@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
 <7G-JlKV_geKWK_AWgsJuh9f5roNYj7e4l07NxXDdo2o=.d86a96e6-0a0d-4003-b7a7-00ac6aa73bc3@github.com>
Message-ID: <r-eEbcZ51jYWLxnRzfnr9odQYGI9060KMxSbESka700=.2209cf0b-9fe0-443f-8b83-6fcdca6d34f1@github.com>

On Tue, 23 Aug 2022 22:22:21 GMT, Phil Race <prr at openjdk.org> wrote:

> Although I've reviewed the CSR I'd prefer it not be finalized yet. I think it needs more changes. The spec is SILENT about what then happens if length is negative and SILENT about an out of range offset too. I think we should address these issues as well.
> 
> Also everywhere - in the CSR and the bug description and summary the text said the method is called setCharacterAttribute whereas it is setCharacterAttributes.

For negative length, now it just returns the control without processing it whereas before it used to raise an exception in arrayCopy method. Upper bound for length should be the text length(which is to be modified/added) I feel, still even if it crosses overall text size that case is handled by limiting to text length. These are not mentioned in spec, so should we modify the spec by adding the range bounds for length......?

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From duke at openjdk.org  Wed Aug 24 07:13:56 2022
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 24 Aug 2022 07:13:56 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
Message-ID: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>

Could you please review the JDK-8292848 bug fixes?
The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
result should be true after version 8.
I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
detect the new os version.
I also changed the method name to match the new conditions.

-------------

Commit messages:
 - 8292848: AWT_Mixing and TrayIcon tests fail on el8 with hard-coded isOel7
 - 8292848: AWT_Mixing and TrayIcon tests fail on el8 with hard-coded isOel7

Changes: https://git.openjdk.org/jdk/pull/9995/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9995&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292848
  Stats: 69 lines in 12 files changed: 19 ins; 0 del; 50 mod
  Patch: https://git.openjdk.org/jdk/pull/9995.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9995/head:pull/9995

PR: https://git.openjdk.org/jdk/pull/9995


From tr at openjdk.org  Wed Aug 24 07:53:17 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 24 Aug 2022 07:53:17 GMT
Subject: RFR: 4834298: JFileChooser.getSelectedFiles() failed with
 multi-selection and double-click
Message-ID: <txQleI8j4XOqDQPMqXmvX419fcqHHFEBy7osuxMXXU8=.b235e18f-9462-4974-b49f-8dab3e644a1b@github.com>

JFileChooser.getSelectedFiles() failed to retrieve files with multi-selection and double-click. This occurs when a single file is selected then enable multi-selection then select the same file through mouse double-click(Two file chooser dialogs used before and after multi-selection enabled). SelectedFiles are updated when a change in files/directory selection is done or when selection is made through keyboard selection. In this case since a single file is selected before multi-selection is enabled and same file is selected again without changing the selection index/directory, leaving selected Files un-updated. 
**Proposed Fix** : Whenever Multi-Selection is enabled check if any files are selected, if yes update the selected Files of JFileChoooser.

-------------

Commit messages:
 - Fix - Updated filepane with fix and added test case
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - Merge branch 'master' of github.com:TejeshR13/jdk
 - Merge branch 'openjdk:master' into master
 - Merge remote-tracking branch 'upstream/master'
 - Merge remote-tracking branch 'upstream/master'
 - ... and 2 more: https://git.openjdk.org/jdk/compare/77398430...7129054a

Changes: https://git.openjdk.org/jdk/pull/9996/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-4834298
  Stats: 106 lines in 2 files changed: 106 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9996.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9996/head:pull/9996

PR: https://git.openjdk.org/jdk/pull/9996


From avu at openjdk.org  Wed Aug 24 13:37:16 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 24 Aug 2022 13:37:16 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline [v2]
In-Reply-To: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
Message-ID: <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>

> Reuse displaysync thread for subsequent updates

Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:

  8290344: Start/stop displaysync affects performance in metal rendering pipeline
  
  Reuse displaysync thread for subsequent updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9512/files
  - new: https://git.openjdk.org/jdk/pull/9512/files/b0036fb9..1f17b0be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9512&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9512&range=00-01

  Stats: 73947 lines in 1600 files changed: 37572 ins; 29641 del; 6734 mod
  Patch: https://git.openjdk.org/jdk/pull/9512.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9512/head:pull/9512

PR: https://git.openjdk.org/jdk/pull/9512


From avu at openjdk.org  Wed Aug 24 13:43:12 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Wed, 24 Aug 2022 13:43:12 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline
In-Reply-To: <rk0is4t4zBEVdDYeouA2ii_XYQMv2x6mtrtfReS0AHY=.1e8c5e72-cac1-4fbf-860a-22699658769a@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
 <M7cubXskcQYIJ_F8i-UfmMRgl2tlZTYUZy6XqmX1Lmk=.f35f88ca-fc05-4b92-928a-43597afedf5d@github.com>
 <rk0is4t4zBEVdDYeouA2ii_XYQMv2x6mtrtfReS0AHY=.1e8c5e72-cac1-4fbf-860a-22699658769a@github.com>
Message-ID: <aCjravYDMyrqhvS1tbI3-A0BGGMHeUCktare05mU1s8=.2773e069-87fb-4372-b02e-a3d8b89faccc@github.com>

On Mon, 1 Aug 2022 17:48:18 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> > Looking at the RenderPerfTest numbers ClipFlatOvalAA went down .. but everything else improved by at the very least a statistically significant amount so why did that one test get worse ?
> 
> I'm unable to re-run the testing because of a regression [JDK-8291266](https://bugs.openjdk.org/browse/JDK-8291266). I'll be back to this pull request after resolving the regression.

I've re-run RenderPerfTest 5 times and used a median for each test case. So, now there are no regressions.

-------------

PR: https://git.openjdk.org/jdk/pull/9512


From honkar at openjdk.org  Wed Aug 24 16:27:31 2022
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 24 Aug 2022 16:27:31 GMT
Subject: Integrated: JDK-8290469: Add new positioning options to PassFailJFrame
 test framework
In-Reply-To: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
References: <Adfv94N3h07CLa45IXitiyDgJC0QYUpc1B4sRbTEcDI=.a4d3f9e1-10eb-4741-afd4-1976f7e52730@github.com>
Message-ID: <Lilui1AG0HWJxsKepNKsk87gc8V3NoFGc67_wGnxUVo=.a6e6f93d-086a-4c7b-8386-ff5d9c25f3a7@github.com>

On Sat, 16 Jul 2022 01:00:43 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Additional position setting (TOP_LEFT_CORNER) and a method to obtain bounds of test instruction frame are added to PassFailJFrame to handle positioning of multiple test frames.
> 
> In scenarios where multiple test windows might be present, the test windows might overlap the instruction frame. In order to fix this TOP_LEFT_CORNER position option is added that positions the test instruction frame at top left corner with main test window below it.
> 
> Additionally `getInstructionFrameBounds()` is added to obtain the position and dimensions of test instruction frame.

This pull request has now been integrated.

Changeset: 568be58e
Author:    Harshitha Onkar <honkar at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/568be58e8521e5e87baca1872ba8cc1941607bb7
Stats:     238 lines in 10 files changed: 133 ins; 50 del; 55 mod

8290469: Add new positioning options to PassFailJFrame test framework

Reviewed-by: prr, aivanov

-------------

PR: https://git.openjdk.org/jdk/pull/9525


From duke at openjdk.org  Wed Aug 24 16:45:35 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 24 Aug 2022 16:45:35 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v23]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <7oaiRHGU5Ts2DhvwrthhF9kvAiVc79cdccGZ7nS8JPY=.bbde837a-3958-473e-9693-2e41049c1cc0@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Updated as per review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/5526919c..dac1ae7d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=21-22

  Stats: 59 lines in 2 files changed: 20 ins; 10 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Wed Aug 24 16:45:38 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Wed, 24 Aug 2022 16:45:38 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v22]
In-Reply-To: <vGGX3jfHiNVf781TbkpEGBvXTIbteGivaQytFsTIufI=.bf9c6f3b-939b-4566-9fcc-b19536d3235f@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <NViC-ENZFMOxUzMlAta92OURfx31rHaUaVTeK2jnAXg=.889c8747-a819-44ea-b1af-712c91ccc7b9@github.com>
 <vGGX3jfHiNVf781TbkpEGBvXTIbteGivaQytFsTIufI=.bf9c6f3b-939b-4566-9fcc-b19536d3235f@github.com>
Message-ID: <4WTjN8ri98MH8PDXt7DuRIaXD5jnu3NWSDbOoAR4DH0=.9314af75-c73b-476c-af26-9adb1458ece8@github.com>

On Mon, 22 Aug 2022 15:40:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated as per review comment
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1187:
> 
>> 1185:             // TODO: it's rather a temporary trick, to be revised
>> 1186:             String text;
>> 1187:             Object[] objs = new Object[1];
> 
> I suggest moving this declaration into the following block:
> 
> 
>             } else if (value instanceof Long len) {
>                 Object[] objs = new Object[1];
> 
>                 if (listViewWindowsStyle) {
> 
> 
> This will reduce the visibility of the variable to the block where it's used.
> 
> Giving it a descriptive name would also be better. Is `fileSize` good enough? `displayedFileSize`?

Implemented the suggested changes. Replaced the variable name "objs" with "displayedFileSize".

> test/jdk/javax/swing/JFileChooser/FileSizeCheck.java line 65:
> 
>> 63:         JFrame frame = new JFrame("JFileChooser File Size test");
>> 64:         JFileChooser fc = new JFileChooser();
>> 65:         Path dir = Paths.get(System.getProperty("test.src"));
> 
> When run with jtreg, it creates the files in the test source tree, which is probably not what we want. If the files aren't removed, they'll be left in the source tree and may prevent further updates to the source.
> 
> Should this always default to the current directory? When `jtreg` runs a test, the current directory is a `scratch` directory which is cleaned between the tests if the test passes, if the test fails, the contents is copied to the test log directory.

I have changed the directory from "test.src" to current directory as suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Wed Aug 24 17:11:26 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 24 Aug 2022 17:11:26 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <r-eEbcZ51jYWLxnRzfnr9odQYGI9060KMxSbESka700=.2209cf0b-9fe0-443f-8b83-6fcdca6d34f1@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
 <7G-JlKV_geKWK_AWgsJuh9f5roNYj7e4l07NxXDdo2o=.d86a96e6-0a0d-4003-b7a7-00ac6aa73bc3@github.com>
 <r-eEbcZ51jYWLxnRzfnr9odQYGI9060KMxSbESka700=.2209cf0b-9fe0-443f-8b83-6fcdca6d34f1@github.com>
Message-ID: <mnpfbBZHLm1D8xiM_QWfckRPUDCiQZY_sjhtarqEWQI=.81ab74fa-0663-4c2f-aaf9-b3ba91a30348@github.com>

On Wed, 24 Aug 2022 05:49:20 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Although I've reviewed the CSR I'd prefer it not be finalized yet. I think it needs more changes. The spec is SILENT about what then happens if length is negative and SILENT about an out of range offset too. I think we should address these issues as well.
> > Also everywhere - in the CSR and the bug description and summary the text said the method is called setCharacterAttribute whereas it is setCharacterAttributes.
> 
> For negative length, now it just returns the control without processing it whereas before it used to raise an exception in arrayCopy method. Upper bound for length should be the text length(which is to be modified/added) I feel, still even if it crosses overall text size that case is handled by limiting to text length. These are not mentioned in spec, so should we modify the spec by adding the range bounds for length......?

Yes I am saying we should mention all of this

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From aturbanov at openjdk.org  Wed Aug 24 18:16:59 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 24 Aug 2022 18:16:59 GMT
Subject: RFR: 8292850: Unused field 'expiredTimersKey' in
 javax.swing.TimerQueue
Message-ID: <6AJdh0g0NneBzT3eDifux9zAt-Wm5XQiavZBpET2HEI=.f9675095-5b0c-473f-8811-ec88533d227c@github.com>

8292850: Unused field 'expiredTimersKey' in javax.swing.TimerQueue

-------------

Commit messages:
 - 8292850: Unused field 'expiredTimersKey' in javax.swing.TimerQueue

Changes: https://git.openjdk.org/jdk/pull/10001/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10001&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292850
  Stats: 9 lines in 1 file changed: 0 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10001.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10001/head:pull/10001

PR: https://git.openjdk.org/jdk/pull/10001


From tr at openjdk.org  Wed Aug 24 18:38:21 2022
From: tr at openjdk.org (Tejesh R)
Date: Wed, 24 Aug 2022 18:38:21 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <mnpfbBZHLm1D8xiM_QWfckRPUDCiQZY_sjhtarqEWQI=.81ab74fa-0663-4c2f-aaf9-b3ba91a30348@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
 <7G-JlKV_geKWK_AWgsJuh9f5roNYj7e4l07NxXDdo2o=.d86a96e6-0a0d-4003-b7a7-00ac6aa73bc3@github.com>
 <r-eEbcZ51jYWLxnRzfnr9odQYGI9060KMxSbESka700=.2209cf0b-9fe0-443f-8b83-6fcdca6d34f1@github.com>
 <mnpfbBZHLm1D8xiM_QWfckRPUDCiQZY_sjhtarqEWQI=.81ab74fa-0663-4c2f-aaf9-b3ba91a30348@github.com>
Message-ID: <HYLWzHheVks1INB1dWaA2s67Rtjzcn-UtgfwhI_pAOg=.1723e65e-3905-4bfe-9fc9-a794838ca202@github.com>

On Wed, 24 Aug 2022 17:08:11 GMT, Phil Race <prr at openjdk.org> wrote:

> > > Although I've reviewed the CSR I'd prefer it not be finalized yet. I think it needs more changes. The spec is SILENT about what then happens if length is negative and SILENT about an out of range offset too. I think we should address these issues as well.
> > > Also everywhere - in the CSR and the bug description and summary the text said the method is called setCharacterAttribute whereas it is setCharacterAttributes.
> > 
> > 
> > For negative length, now it just returns the control without processing it whereas before it used to raise an exception in arrayCopy method. Upper bound for length should be the text length(which is to be modified/added) I feel, still even if it crosses overall text size that case is handled by limiting to text length. These are not mentioned in spec, so should we modify the spec by adding the range bounds for length......?
> 
> Yes I am saying we should mention all of this

Will this addition to spec be fine -      

      * A write lock is held by this operation while changes
      * are being made, and a DocumentEvent is sent to the listeners
      * after the change has been successfully completed.
+     *
+     * <p>
+     * The expected {@Code length} range is the length of the text
+     * in which the attributes are set. If the length is &lt;= 0, then no
+     * attributes are set, the control returns. If the length is &gt; the
+     * length of text in which the attributes are to be set then the
+     * extra length is trimmed.
+     * </p>
+     *
      * <p>
      * This method is thread safe, although most Swing methods
      * are not. Please see

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From dnguyen at openjdk.org  Wed Aug 24 19:44:21 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 24 Aug 2022 19:44:21 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <PekUUNpC2oxcidxOrEBr-JOmBIyrANdJo0k37mDH1tU=.edd6d308-421c-4b4b-a71e-a6b885e1c71a@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
 <aiGrm0biUjAb0wZAsbR2fW7bvKYjGeNoYug1MLvOk3A=.5f43448f-0636-4ddd-a73c-580381cb955f@github.com>
 <PekUUNpC2oxcidxOrEBr-JOmBIyrANdJo0k37mDH1tU=.edd6d308-421c-4b4b-a71e-a6b885e1c71a@github.com>
Message-ID: <zzYK6ifQ3-9sKp9jT1LY3DCcwPa4MV6uMmcgptzjCSk=.8c35f68f-a661-4a1d-8be4-9b10feb757b8@github.com>

On Tue, 23 Aug 2022 05:45:34 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > @andy-goryachev-oracle I took into consideration your comment regarding RTL and LTR behavior regarding JComboBoxes. I did the testing as we briefly discussed and all results led me to believe Aqua L&F combo boxes only supported the button being on the right. Will still need to check with a device natively set to RTL, but it turns out a nearly decade old JBS issue already exists for this JComboBox button issue. I'll leave that separate from this PR and possibly look into that other issue later.
> 
> Yes, [JDK-8023912](https://bugs.openjdk.org/browse/JDK-8023912)... I am not sure if this RTL is an issue. I guess it was mentioned in our meeting that RTL should not affect JComboBox button. Maybe another question for apple, since the button image drawn by JRS?

I believe the question regarding font sizes was already sent to Apple last week. I can definitely add it to my ever-growing list of questions to Apple, but I was advised to keep this question to Apple focused on this particular issue.

-------------

PR: https://git.openjdk.org/jdk/pull/9473


From aivanov at openjdk.org  Wed Aug 24 19:50:10 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 24 Aug 2022 19:50:10 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v23]
In-Reply-To: <7oaiRHGU5Ts2DhvwrthhF9kvAiVc79cdccGZ7nS8JPY=.bbde837a-3958-473e-9693-2e41049c1cc0@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <7oaiRHGU5Ts2DhvwrthhF9kvAiVc79cdccGZ7nS8JPY=.bbde837a-3958-473e-9693-2e41049c1cc0@github.com>
Message-ID: <2D65JrpEgph34GcC_G2luDZOoqPXB5fWxKp75k8bgnA=.28d77e32-7423-4450-afd1-fb47df9f8214@github.com>

On Wed, 24 Aug 2022 16:45:35 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per review comments

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/swing/FilePane.java line 1199:

> 1197:             } else if (value instanceof Long len) {
> 1198:                 /*
> 1199:                  * Code block is relevant to Linux.

Suggestion:

                 * This code block is relevant to Linux.

I feel that a determiner is missing here: _This_ or _The_. Any native English speakers?

src/java.desktop/share/classes/sun/swing/FilePane.java line 1200:

> 1198:                 /*
> 1199:                  * Code block is relevant to Linux.
> 1200:                  * File size is display up to 1 decimal precision.

Suggestion:

                 * File size is displayed up to 1 decimal precision.

Sorry, I missed it yesterday when I added _?is?_.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1201:

> 1199:                  * Code block is relevant to Linux.
> 1200:                  * File size is display up to 1 decimal precision.
> 1201:                  * Base-10 number system used for formatting file size

Suggestion:

                 * Base-10 number system is used for formatting file size

With explicit _?is?_, it sounds better to me.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1269:

> 1267:          * Returns the file size in one decimal precision.
> 1268:          */
> 1269:         private static double formatToDoubleValue(long fileSize) {

Suggestion:

        /**
         * Rounds a value to one decimal place. It's used to format
         * file size similar to how it's formatted in file managers on Linux.
         *
         * @param len the file size to round to one decimal place
         * @return file size rounded to one decimal place
         */
        private static double roundToOneDecimalPlace(long fileSize) {

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Wed Aug 24 23:33:31 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 24 Aug 2022 23:33:31 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <HYLWzHheVks1INB1dWaA2s67Rtjzcn-UtgfwhI_pAOg=.1723e65e-3905-4bfe-9fc9-a794838ca202@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
 <7G-JlKV_geKWK_AWgsJuh9f5roNYj7e4l07NxXDdo2o=.d86a96e6-0a0d-4003-b7a7-00ac6aa73bc3@github.com>
 <r-eEbcZ51jYWLxnRzfnr9odQYGI9060KMxSbESka700=.2209cf0b-9fe0-443f-8b83-6fcdca6d34f1@github.com>
 <mnpfbBZHLm1D8xiM_QWfckRPUDCiQZY_sjhtarqEWQI=.81ab74fa-0663-4c2f-aaf9-b3ba91a30348@github.com>
 <HYLWzHheVks1INB1dWaA2s67Rtjzcn-UtgfwhI_pAOg=.1723e65e-3905-4bfe-9fc9-a794838ca202@github.com>
Message-ID: <wziqCtepaHS-aHMGocZFlCOfgD7U8EUrFNAtg1Gs6pA=.f2775736-bf0c-4570-9cd7-0a7908c9e72c@github.com>

On Wed, 24 Aug 2022 18:34:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > > Although I've reviewed the CSR I'd prefer it not be finalized yet. I think it needs more changes. The spec is SILENT about what then happens if length is negative and SILENT about an out of range offset too. I think we should address these issues as well.
> > > > Also everywhere - in the CSR and the bug description and summary the text said the method is called setCharacterAttribute whereas it is setCharacterAttributes.
> > > 
> > > 
> > > For negative length, now it just returns the control without processing it whereas before it used to raise an exception in arrayCopy method. Upper bound for length should be the text length(which is to be modified/added) I feel, still even if it crosses overall text size that case is handled by limiting to text length. These are not mentioned in spec, so should we modify the spec by adding the range bounds for length......?
> > 
> > 
> > Yes I am saying we should mention all of this
> 
> Will this addition to spec be fine -
> 
> ```
>       * A write lock is held by this operation while changes
>       * are being made, and a DocumentEvent is sent to the listeners
>       * after the change has been successfully completed.
> +     *
> +     * <p>
> +     * The expected {@Code length} range is the length of the text
> +     * in which the attributes are set. If the length is &lt;= 0, then no
> +     * attributes are set, the control returns. If the length is &gt; the
> +     * length of text in which the attributes are to be set then the
> +     * extra length is trimmed.
> +     * </p>
> +     *
>       * <p>
>       * This method is thread safe, although most Swing methods
>       * are not. Please see
> ```

should be {@code .. } 
And the control doesn't return, the method does. I think you were trying to say control returns to the caller but that doesn't work here and the interaction with offset is cryptic .. assuming that's the reference to "trimmed".
Something that makes clear that the replace arg isn't used in such a case might help too.

I expect something like

     * {@code offset} and {@code length} define the range of the text over which the attributes are set.
     * If the length is &lt;= 0, then no action is taken  and the method just returns.
     * If the offset is < 0 or >= the length of the text then no action is taken, and the method just returns
     *  Otherwise if {@code offset + length} will exceed the length of the  text then the affected range is truncated to that length
     * 
But YOU  need to verify this is all actually true ..

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From prr at openjdk.org  Wed Aug 24 23:51:33 2022
From: prr at openjdk.org (Phil Race)
Date: Wed, 24 Aug 2022 23:51:33 GMT
Subject: RFR: JDK-8292715: Cleanup Problemlist [v2]
In-Reply-To: <p6iiFOTBS62SvrkWojvB3YS73qoaNgOmpoOBgkEuDV4=.3b029dbc-79c1-446e-9765-9f63d620fb66@github.com>
References: <vcp-zpylU9cS1Eq66cSnTLSGo5cuzzfUdzLrGlVx880=.b5e40ddb-b793-4353-84fb-d77a9a88c04b@github.com>
 <p6iiFOTBS62SvrkWojvB3YS73qoaNgOmpoOBgkEuDV4=.3b029dbc-79c1-446e-9765-9f63d620fb66@github.com>
Message-ID: <3PDWEwjyZy8jqmifU5NvUboQO_BWY-PJyIagVXQppgw=.8ea1b0a6-e32a-444a-8cf1-ac05d21e7e31@github.com>

On Tue, 23 Aug 2022 04:06:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Cleanup of Problemlist
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Seggregate swing and awt manual tests as part of cleanup

Approved on the understanding (since you did not say) that you have verified all de-listed tests do pass.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9963


From tr at openjdk.org  Thu Aug 25 03:15:43 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 25 Aug 2022 03:15:43 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v4]
In-Reply-To: <wziqCtepaHS-aHMGocZFlCOfgD7U8EUrFNAtg1Gs6pA=.f2775736-bf0c-4570-9cd7-0a7908c9e72c@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <mv3p9QkFv_oF-UXCGaBx7UU077igu67_vC2vgNLK-ps=.adcb80a4-1bea-4654-9229-d2a11a2026a7@github.com>
 <7G-JlKV_geKWK_AWgsJuh9f5roNYj7e4l07NxXDdo2o=.d86a96e6-0a0d-4003-b7a7-00ac6aa73bc3@github.com>
 <r-eEbcZ51jYWLxnRzfnr9odQYGI9060KMxSbESka700=.2209cf0b-9fe0-443f-8b83-6fcdca6d34f1@github.com>
 <mnpfbBZHLm1D8xiM_QWfckRPUDCiQZY_sjhtarqEWQI=.81ab74fa-0663-4c2f-aaf9-b3ba91a30348@github.com>
 <HYLWzHheVks1INB1dWaA2s67Rtjzcn-UtgfwhI_pAOg=.1723e65e-3905-4bfe-9fc9-a794838ca202@github.com>
 <wziqCtepaHS-aHMGocZFlCOfgD7U8EUrFNAtg1Gs6pA=.f2775736-bf0c-4570-9cd7-0a7908c9e72c@github.com>
Message-ID: <WCxVFv4auTnqreVUQ6yq1quCuEyxy-0J_KOPsoby-9c=.7615afe5-7a18-47bf-96ca-59616bb41955@github.com>

On Wed, 24 Aug 2022 23:28:55 GMT, Phil Race <prr at openjdk.org> wrote:

> > > > > Although I've reviewed the CSR I'd prefer it not be finalized yet. I think it needs more changes. The spec is SILENT about what then happens if length is negative and SILENT about an out of range offset too. I think we should address these issues as well.
> > > > > Also everywhere - in the CSR and the bug description and summary the text said the method is called setCharacterAttribute whereas it is setCharacterAttributes.
> > > > 
> > > > 
> > > > For negative length, now it just returns the control without processing it whereas before it used to raise an exception in arrayCopy method. Upper bound for length should be the text length(which is to be modified/added) I feel, still even if it crosses overall text size that case is handled by limiting to text length. These are not mentioned in spec, so should we modify the spec by adding the range bounds for length......?
> > > 
> > > 
> > > Yes I am saying we should mention all of this
> > 
> > 
> > Will this addition to spec be fine -
> > ```
> >       * A write lock is held by this operation while changes
> >       * are being made, and a DocumentEvent is sent to the listeners
> >       * after the change has been successfully completed.
> > +     *
> > +     * <p>
> > +     * The expected {@Code length} range is the length of the text
> > +     * in which the attributes are set. If the length is &lt;= 0, then no
> > +     * attributes are set, the control returns. If the length is &gt; the
> > +     * length of text in which the attributes are to be set then the
> > +     * extra length is trimmed.
> > +     * </p>
> > +     *
> >       * <p>
> >       * This method is thread safe, although most Swing methods
> >       * are not. Please see
> > ```
> 
> should be {@code .. } And the control doesn't return, the method does. I think you were trying to say control returns to the caller but that doesn't work here and the interaction with offset is cryptic .. assuming that's the reference to "trimmed". Something that makes clear that the replace arg isn't used in such a case might help too.
> 
> I expect something like
> 
> ```
>  * {@code offset} and {@code length} define the range of the text over which the attributes are set.
>  * If the length is &lt;= 0, then no action is taken  and the method just returns.
>  * If the offset is < 0 or >= the length of the text then no action is taken, and the method just returns
>  *  Otherwise if {@code offset + length} will exceed the length of the  text then the affected range is truncated to that length
>  * 
> ```
> 
> But YOU need to verify this is all actually true ..

Yes @prrace , I have verified this and I will update the spec. Except `offset is <= 0 or > the length` everything is right.

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From tr at openjdk.org  Thu Aug 25 03:27:49 2022
From: tr at openjdk.org (Tejesh R)
Date: Thu, 25 Aug 2022 03:27:49 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v5]
In-Reply-To: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
Message-ID: <gdG66T9Gd8VPUtr4zeLCqHL9HfFJtFNVZE3Mdq7fqjs=.68f35333-36dc-4460-ae57-5cf15cb64c84@github.com>

> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Updated based on review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9830/files
  - new: https://git.openjdk.org/jdk/pull/9830/files/e812f009..adde88d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9830&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9830&range=03-04

  Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/9830.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9830/head:pull/9830

PR: https://git.openjdk.org/jdk/pull/9830


From psadhukhan at openjdk.org  Thu Aug 25 03:39:12 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 25 Aug 2022 03:39:12 GMT
Subject: RFR: JDK-8292715: Cleanup Problemlist [v2]
In-Reply-To: <3PDWEwjyZy8jqmifU5NvUboQO_BWY-PJyIagVXQppgw=.8ea1b0a6-e32a-444a-8cf1-ac05d21e7e31@github.com>
References: <vcp-zpylU9cS1Eq66cSnTLSGo5cuzzfUdzLrGlVx880=.b5e40ddb-b793-4353-84fb-d77a9a88c04b@github.com>
 <p6iiFOTBS62SvrkWojvB3YS73qoaNgOmpoOBgkEuDV4=.3b029dbc-79c1-446e-9765-9f63d620fb66@github.com>
 <3PDWEwjyZy8jqmifU5NvUboQO_BWY-PJyIagVXQppgw=.8ea1b0a6-e32a-444a-8cf1-ac05d21e7e31@github.com>
Message-ID: <ZlwFpnqvuesvkGHyXHsMFcC4UkTfBJuThziRJ1Lqjns=.46f97038-28a3-4c38-948a-171faf00d543@github.com>

On Wed, 24 Aug 2022 23:48:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Approved on the understanding (since you did not say) that you have verified all de-listed tests do pass.

Since I listed the mach5 job in the closed PR running all tests both open and closed which has passed so I did not mention explicitly here.

-------------

PR: https://git.openjdk.org/jdk/pull/9963


From duke at openjdk.org  Thu Aug 25 04:43:58 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 25 Aug 2022 04:43:58 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v24]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <r-TkXoxVEb0Gyjxw18x4e_bp3mIIcBcFHJ69PZVUt_w=.03881b13-dc07-4074-b423-cfba8c7d926e@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Comments modified and formatToDoubleValue method name renamed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/dac1ae7d..1e086cae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=22-23

  Stats: 10 lines in 1 file changed: 2 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Thu Aug 25 05:13:48 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Thu, 25 Aug 2022 05:13:48 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v16]
In-Reply-To: <0L_5nT7vcXiJdTIiF_ve5LuWyIZr7CSTkZ22nM7vIDs=.38dce724-3867-4d5f-820e-d45d98297760@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <DGUVwqO-2n_q4RYN5asQGlstavIUAlQjofYYHIhtHuo=.5f64c904-7263-40e9-8f67-38ac040c123c@github.com>
 <Mob16bWMjoymF5RoSMaTCfGWk6qc4gdKCzNX6U1enr0=.a33baf4e-b0ad-44ac-95fa-b283026f7850@github.com>
 <37PLBrSt3h8f3b0vxFRl4HwHpKwCkWaymy-sHGMMgic=.2d56b930-8377-45e1-8264-a83a55789cd5@github.com>
 <0L_5nT7vcXiJdTIiF_ve5LuWyIZr7CSTkZ22nM7vIDs=.38dce724-3867-4d5f-820e-d45d98297760@github.com>
Message-ID: <cuNf0LZWe1r_uwpvjNvSa-_yFqzO5jGSvqA-n000qAI=.ec9ed3b4-2e7d-4391-a472-913451794c0d@github.com>

On Mon, 22 Aug 2022 15:33:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> @prrace 
>> 
>> } else if (len < 1024L) {
>> ...
>> } has been removed in previous commit. 
>> So if listViewWindowsStyle is false then the next else if will be executed i.e. <100L.
>
>> } else if (len < 1024L) { ... } has been removed in previous commit. So if listViewWindowsStyle is false then the next else if will be executed i.e. <100L.
> 
> For clarity, would it be better to separate the cases?
> 
> 
>                 if (listViewWindowsStyle) {
>                     if (len == 0) {
>                 } else {
>                     if (len < 100L) {
>                 }
> 
> 
> This would increase the indentation level, yet it would make the code clearer. Now two independent conditions are chained.

@aivanov-jdk Comments and method name has been changed as suggested.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From psadhukhan at openjdk.org  Thu Aug 25 07:32:46 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 25 Aug 2022 07:32:46 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear.
Message-ID: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>

When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.

Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)

closed problemlisted test is used to check the fix.

-------------

Commit messages:
 - 7148092: [macosx] When Alt+down arrow key is pressed, the combobox popup does not appear.

Changes: https://git.openjdk.org/jdk/pull/10014/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7148092
  Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10014.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10014/head:pull/10014

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Thu Aug 25 07:38:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 25 Aug 2022 07:38:39 GMT
Subject: Integrated: JDK-8292715: Cleanup Problemlist
In-Reply-To: <vcp-zpylU9cS1Eq66cSnTLSGo5cuzzfUdzLrGlVx880=.b5e40ddb-b793-4353-84fb-d77a9a88c04b@github.com>
References: <vcp-zpylU9cS1Eq66cSnTLSGo5cuzzfUdzLrGlVx880=.b5e40ddb-b793-4353-84fb-d77a9a88c04b@github.com>
Message-ID: <0rJsFzW713Dt8WyEJRXqCyyHNgdCZkMkly4E8VIsNAU=.cfa2ffcc-52cf-4513-83ea-4bd8b88ccd14@github.com>

On Mon, 22 Aug 2022 11:23:08 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Cleanup of Problemlist

This pull request has now been integrated.

Changeset: 5a20bc44
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5a20bc44b1fb4edb6ab714191cdc6c3f33ac9836
Stats:     12 lines in 1 file changed: 5 ins; 6 del; 1 mod

8292715: Cleanup Problemlist

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/9963


From psadhukhan at openjdk.org  Thu Aug 25 08:00:38 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 25 Aug 2022 08:00:38 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v2]
In-Reply-To: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
Message-ID: <Med-DWuCzFNE6uxkbOnOGfLu0Lk_wENk1nkxyl4JxH8=.8106ccdf-31b8-488c-9bae-df541cface4c@github.com>

> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
> 
> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
> 
> closed problemlisted test is used to check the fix.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Fix as seen in native combobox

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10014/files
  - new: https://git.openjdk.org/jdk/pull/10014/files/d10c84cf..4c76b582

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=00-01

  Stats: 28 lines in 2 files changed: 21 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/10014.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10014/head:pull/10014

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Thu Aug 25 08:00:39 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 25 Aug 2022 08:00:39 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear.
In-Reply-To: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
Message-ID: <HdXIMOa6LcCuYcErU-QR3ovoo7NQ0q7VDtC3Z8vxgM0=.adc181b7-2a7a-42b4-a830-4744b3065e48@github.com>

On Thu, 25 Aug 2022 07:24:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
> 
> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
> 
> closed problemlisted test is used to check the fix.

It seems macos native combox does something extra. 
When Alt+Down is pressed on combobox, it opens up the popup but if the popup is already opened, it selects the last entry.
When Alt+Up is pressed on combobox, it opens up the popup but if the popup is already opened, it selects the first entry.

Modified the fix to behave same as native combobox.

-------------

PR: https://git.openjdk.org/jdk/pull/10014


From mbaesken at openjdk.org  Thu Aug 25 08:09:08 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 Aug 2022 08:09:08 GMT
Subject: RFR: JDK-8292866: Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation
 check MultiByteToWideChar return value for failures
Message-ID: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>

https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).

-------------

Commit messages:
 - JDK-8292866

Changes: https://git.openjdk.org/jdk/pull/10015/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10015&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292866
  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10015.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10015/head:pull/10015

PR: https://git.openjdk.org/jdk/pull/10015


From dnguyen at openjdk.org  Thu Aug 25 14:35:40 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 25 Aug 2022 14:35:40 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v5]
In-Reply-To: <43FdnqPZXOC5g91vHiuRZtXE10o52m0eJj0yAvF98ME=.54da3a9c-c978-4c43-8448-10c0149dc966@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <2WFsgc4z6xE1yQQl2_LQxnr3ji7Uwrp0KtzucAz_mUQ=.941647bc-f562-41b6-af06-9dfca2262d81@github.com>
 <0G0zF5bYaz6Yu2zRZHmbuYTSqQgWacbkdORWMvN7O-0=.2a330d4d-41b9-4e03-b8e2-76b99e45dc8d@github.com>
 <43FdnqPZXOC5g91vHiuRZtXE10o52m0eJj0yAvF98ME=.54da3a9c-c978-4c43-8448-10c0149dc966@github.com>
Message-ID: <RIzX_1Bs0s5L8jNWr12pqmZnedopL3o7z-hlXhzzwWI=.f679400d-e6e4-4a00-89eb-832da0c47cbc@github.com>

On Mon, 15 Aug 2022 17:52:05 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> I am not sure if this is correct approach... Have you seen any macos documentation citing combobox height should not increase even if font size change? That might be problematic for say, accessibility usecase, for slight visually impaired more hearing impaired, where we need to draw them big, right?

Through Phil, Apple has confirmed that the height of the JComboBox should be fixed. The reason being that the UI was designed around a control font size, and other UI such as button backgrounds and other related elements also have fixed height. The UI's height being resizable is possible, but is not intended for Aqua.

So I believe this fix aligns with that philosophy and is an OK way of resolving the discrepancy between editable & non-editable JComboBoxes in Aqua L&F.

-------------

PR: https://git.openjdk.org/jdk/pull/9473


From angorya at openjdk.org  Thu Aug 25 14:54:45 2022
From: angorya at openjdk.org (Andy Goryachev)
Date: Thu, 25 Aug 2022 14:54:45 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v2]
In-Reply-To: <Med-DWuCzFNE6uxkbOnOGfLu0Lk_wENk1nkxyl4JxH8=.8106ccdf-31b8-488c-9bae-df541cface4c@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <Med-DWuCzFNE6uxkbOnOGfLu0Lk_wENk1nkxyl4JxH8=.8106ccdf-31b8-488c-9bae-df541cface4c@github.com>
Message-ID: <qPgl00oIBqY05NgJcITJYXGxV43QtmMSFpfsG2uxi0c=.d31f1f7e-332b-4282-8d5e-3358c725bac5@github.com>

On Thu, 25 Aug 2022 08:00:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
>> 
>> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
>> 
>> closed problemlisted test is used to check the fix.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix as seen in native combobox

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 587:

> 585: 
> 586:     @SuppressWarnings("serial") // anonymous class
> 587:     private final Action openPopupOrhighlightLast = new AbstractAction() {

may be openPopupOrHighlightLast (uppercase H)?

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 602:

> 600: 
> 601:     @SuppressWarnings("serial") // anonymous class
> 602:     private final Action openPopupOrhighlightFirst = new AbstractAction() {

may be openPopupOrHighlightFirst (uppercase H)

-------------

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Thu Aug 25 16:34:32 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 25 Aug 2022 16:34:32 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v3]
In-Reply-To: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
Message-ID: <9_6m09UHBqjqrDWnuPS7Imjl3tciQr1q7RCxyOY0xXs=.47f6bcbe-38db-40c5-86b5-4329d5c365ef@github.com>

> When comboBox have focus, pressing Alt+Down (or Up) should render the popup which is not happening for Aqua L&F.
> 
> Fix is to add toggleAction for Alt+Down/Up keys as has been done for [MetalLookAndFeel](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/metal/MetalLookAndFeel.java#L912)
> 
> closed problemlisted test is used to check the fix.

Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:

  Use camelCase

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10014/files
  - new: https://git.openjdk.org/jdk/pull/10014/files/4c76b582..531dec1f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10014&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10014.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10014/head:pull/10014

PR: https://git.openjdk.org/jdk/pull/10014


From psadhukhan at openjdk.org  Thu Aug 25 16:34:35 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 25 Aug 2022 16:34:35 GMT
Subject: RFR: 7148092: [macosx] When Alt+down arrow key is pressed,
 the combobox popup does not appear. [v2]
In-Reply-To: <qPgl00oIBqY05NgJcITJYXGxV43QtmMSFpfsG2uxi0c=.d31f1f7e-332b-4282-8d5e-3358c725bac5@github.com>
References: <Un8Mtjz3UJxywOAnc1Jbp1SYyPs1b0cCp5zuydBuG9w=.5799a272-d094-46e1-a331-b7c9f2ed0750@github.com>
 <Med-DWuCzFNE6uxkbOnOGfLu0Lk_wENk1nkxyl4JxH8=.8106ccdf-31b8-488c-9bae-df541cface4c@github.com>
 <qPgl00oIBqY05NgJcITJYXGxV43QtmMSFpfsG2uxi0c=.d31f1f7e-332b-4282-8d5e-3358c725bac5@github.com>
Message-ID: <qgaT09dLuMeAl90ThX9fjRvhMkH4orO1E181TVQJMm4=.9f4a73be-0be4-4987-9d86-1ffd7e6df92d@github.com>

On Thu, 25 Aug 2022 14:50:08 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix as seen in native combobox
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 602:
> 
>> 600: 
>> 601:     @SuppressWarnings("serial") // anonymous class
>> 602:     private final Action openPopupOrhighlightFirst = new AbstractAction() {
> 
> may be openPopupOrHighlightFirst (uppercase H)

ok

-------------

PR: https://git.openjdk.org/jdk/pull/10014


From prr at openjdk.org  Thu Aug 25 18:46:22 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Aug 2022 18:46:22 GMT
Subject: RFR: 8292850: Unused field 'expiredTimersKey' in
 javax.swing.TimerQueue
In-Reply-To: <6AJdh0g0NneBzT3eDifux9zAt-Wm5XQiavZBpET2HEI=.f9675095-5b0c-473f-8811-ec88533d227c@github.com>
References: <6AJdh0g0NneBzT3eDifux9zAt-Wm5XQiavZBpET2HEI=.f9675095-5b0c-473f-8811-ec88533d227c@github.com>
Message-ID: <siwnRvx0Wh7aaGgvuis2_W9RGPGRzSbvmXjvNkMK_C4=.1992679f-ab32-467c-b35a-78e06b97bfec@github.com>

On Wed, 24 Aug 2022 18:05:40 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 8292850: Unused field 'expiredTimersKey' in javax.swing.TimerQueue

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10001


From prr at openjdk.org  Thu Aug 25 18:59:10 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Aug 2022 18:59:10 GMT
Subject: RFR: 8292848: AWT_Mixing and TrayIcon tests fail on el8 with
 hard-coded isOel7
In-Reply-To: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
References: <ZJrPLHPk000YQPHb73cCqw1l7jP1vwRLEXMlOgrqVSs=.a599b437-a90f-4f81-8ca5-aa2809bde6f7@github.com>
Message-ID: <aH8UVH574D88IUnIf8B3SlA2NAXBfFxo8lqrnM5CVNc=.6ebdfd83-13e1-4326-acc3-5311a205a4f4@github.com>

On Wed, 24 Aug 2022 07:06:15 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Could you please review the JDK-8292848 bug fixes?
> The purpose of the isOel7 method is to detect differences in GNOME version changes, and the isOel7 
> result should be true after version 8.
> I modified the isOel7 method to use regular expressions instead of hard-coded versions to be able to 
> detect the new os version.
> I also changed the method name to match the new conditions.

I guess this will do what was previously being done on OL7 .. but the way it is done it is fragile
and surely it can't be specific to OL .. and there's some pretty hokey adjustments going on in some of these tests.
I think some day these tests will need to be re-examined.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9995


From prr at openjdk.org  Thu Aug 25 19:22:55 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Aug 2022 19:22:55 GMT
Subject: RFR: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures
In-Reply-To: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
Message-ID: <gH3d2IOG6m21Jr0kiKxYaPMnK4GVzyAqoL9B-ghOIrw=.0159341a-dddf-47d6-9ab5-55c5552acff5@github.com>

On Thu, 25 Aug 2022 08:02:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 724:

> 722:         // IShellFolder::ParseDisplayName requires the path name in Unicode.
> 723:         ret = MultiByteToWideChar(CP_ACP, MB_PRECOMPOSED, strret.cStr, -1, olePath, MAX_PATH);
> 724:         if (ret == 0) return 0;

if (ret == 0) {
    return NULL;
}

Since (1) We always use parens, (2) the other cases return NULL .. unless you want to also change all those to return 0.

-------------

PR: https://git.openjdk.org/jdk/pull/10015


From mkartashev at openjdk.org  Thu Aug 25 19:48:04 2022
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Thu, 25 Aug 2022 19:48:04 GMT
Subject: Integrated: 8292304: [REDO] JDK-8289208 Test
 DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS
In-Reply-To: <hoWXjz5E3xFvx9_1GiiCpl5HM4oyWFguc53_I7B8oRA=.2db225d0-0d6c-484c-8804-c73e4c31f349@github.com>
References: <hoWXjz5E3xFvx9_1GiiCpl5HM4oyWFguc53_I7B8oRA=.2db225d0-0d6c-484c-8804-c73e4c31f349@github.com>
Message-ID: <5wWVcQRkWUqT8NKkfZQcjacjc8B0sWeu3LEYXxd_G04=.34271611-ea43-4d7f-8676-60031a4b03f2@github.com>

On Tue, 16 Aug 2022 08:26:08 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

> See also the [original pull request](https://github.com/openjdk/jdk/pull/9362) where the change is explained and discussed in details.
> 
> Compared to the original version of this fix I
> * changed the error reporting from `printStackTrace()` to `System.out.println()` as per @prrace request,
> * fixed the test to use `AtomicInteger` for the counter of disposer records as `+=` and `--` operations on a `volatile int` do not guarantee value's integrity, which caused the test to often fail.
> 
> `test/jdk/sun/java2d/Disposer/TestDisposerRace.java` now passes successfully on MacOS and Linux.

This pull request has now been integrated.

Changeset: 5d799d80
Author:    Maxim Kartashev <mkartashev at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d799d80e638b85fa3881904e7330ffb5100764a
Stats:     141 lines in 3 files changed: 122 ins; 5 del; 14 mod

8292304: [REDO] JDK-8289208 Test DrawRotatedStringUsingRotatedFont.java occasionally crashes on MacOS

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/9890


From jwaters at openjdk.org  Thu Aug 25 19:49:01 2022
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 25 Aug 2022 19:49:01 GMT
Subject: Integrated: 8292314: Cleanup legacy address handling
In-Reply-To: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
References: <H-atHQWX5ck1f8rDbqsQfbvCwEDnmsNuRHjf_Phtixo=.1aafce0c-47c1-4ab1-b804-90ee05b756e0@github.com>
Message-ID: <0-1sR-uHHj0FX-7wAdkbP_jBW4qiWdwwhhZuSRxUEGg=.68ebcf64-f731-41ee-9eae-921cb7e00c16@github.com>

On Sat, 13 Aug 2022 06:09:33 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Cleanup legacy address check in libsplashscreen obsoleted by http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/75755e92430c

This pull request has now been integrated.

Changeset: 95a33fe1
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95a33fe1502b6f0db2c60fa92b389fda74d94407
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8292314: Cleanup legacy address handling

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/9866


From prr at openjdk.org  Thu Aug 25 19:58:53 2022
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Aug 2022 19:58:53 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
 [v2]
In-Reply-To: <o8HCbCeXAeSvA4lOXtOjQHViiVBFd7ruuICy2a8x0UI=.d6750ed4-e80f-474a-9d08-a8a93ce8f260@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
 <m5FaWGhdBKPXUyNkSIkCToBUxirQZ5Q1LaF-jIQRiVc=.ac78ad2f-6be1-48c5-8a38-4b11e47ae9fe@github.com>
 <o8HCbCeXAeSvA4lOXtOjQHViiVBFd7ruuICy2a8x0UI=.d6750ed4-e80f-474a-9d08-a8a93ce8f260@github.com>
Message-ID: <VSFr0PzV7Xgie_uI9jeDTwb_dLOX0wrpdJ6afoPzCq4=.fb52dd52-a077-4e3a-bb5f-b2951f6e667a@github.com>

On Sun, 21 Aug 2022 21:37:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicRadioButtonUI.java line 148:
>> 
>>> 146: 
>>> 147:         Icon altIcon = b.getIcon();
>>> 148: 
>> 
>> So what's this about ?
>
> I reverted this changes

why ? .. although it seemed they were unused too, it is just that you didn't mention them anywhere and the title doesn't relate to it.

-------------

PR: https://git.openjdk.org/jdk/pull/9832


From psadhukhan at openjdk.org  Fri Aug 26 05:11:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 26 Aug 2022 05:11:47 GMT
Subject: RFR: 6852577: Only for Nimbus LAF
 UIManager.get("PasswordField.echoChar") is null
Message-ID: <pgeYcwu6qn-W4HkJ210qTHot_nHXJokeASDLZ796onw=.8fb91d4d-48a9-49f5-b889-4bf2d29367ac@github.com>

Default echo character obtained through `PasswordField.echoChar` UIProperty returns null for Nimbus L&F,
which is fixed by adding the default character * in the UIDefault table.

-------------

Commit messages:
 - Fix
 - Fix
 - 6852577: Only for Nimbus LAF UIManager.get(PasswordField.echoChar) is null
 - 6852577: Only for Nimbus LAF UIManager.get(PasswordField.echoChar) is null

Changes: https://git.openjdk.org/jdk/pull/10035/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6852577
  Stats: 62 lines in 2 files changed: 62 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10035.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10035/head:pull/10035

PR: https://git.openjdk.org/jdk/pull/10035


From psadhukhan at openjdk.org  Fri Aug 26 07:44:01 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 26 Aug 2022 07:44:01 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
Message-ID: <fLdwg5tf1pNBBPZjaC4kPq8rAR2wR6o61uJj0JPNk6w=.8dae6d77-f220-4c5a-9904-0b77465fd308@github.com>

On Wed, 17 Aug 2022 22:37:46 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> When a JComboBox is editable, the button segment of the combo box is misaligned vertically and has a different height. This change fixes these issues and adds a manual test that checks the appearance of an editable and non-editable JComboBox.
>> 
>> One of the discussions revolving this issue is the native macOS appearance of editable JComboBoxes. After looking through native macOS apps, the only one found is in System Preferences > Date & Time. The problem here is that the native equivalent found here uses a blue button with a single down arrow as the button's symbol. The current swing implementation uses a white button with an up & down arrow symbol for the button. A JRS widget button that has this blue button with a single downward arrow exists but does not support text fields.
>> 
>> As such, I believe the best fix for this issue is to mainly fix the alignment and sizing issue. I looked through Apple's documentation for these UI elements but editable JComboBoxes aren't specifically listed anywhere. Similarly, there's barely any editable JComboBoxes used in native mac apps (only the date & time). So, I don't think it's a major issue if JComboBox does not exactly match the example found in Date & Time.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright date. Added MacOS text to test.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 471:

> 469: 
> 470:             if (comboBox.getComponentOrientation().isLeftToRight()) {
> 471:                 return new Rectangle(insets.left, insets.top + midHeight,

OK. Since Apple has confirmed combobox height shouldn't change with font size, we can have fixed height.

Only thing I guess, till we sort out JDK-8023912: [macosx] JComboBox RTL orientation problem
lets use LTR as it seems it might give a false impression that we support RTL when we dont even know if Apple supports it or not. Do we see any difference with LTR and RTL?

-------------

PR: https://git.openjdk.org/jdk/pull/9473


From mbaesken at openjdk.org  Fri Aug 26 07:54:24 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Aug 2022 07:54:24 GMT
Subject: RFR: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures [v2]
In-Reply-To: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
Message-ID: <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>

> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust added return syntax

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10015/files
  - new: https://git.openjdk.org/jdk/pull/10015/files/e4e71ef7..35960e95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10015&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10015&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10015.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10015/head:pull/10015

PR: https://git.openjdk.org/jdk/pull/10015


From mbaesken at openjdk.org  Fri Aug 26 07:54:25 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 Aug 2022 07:54:25 GMT
Subject: RFR: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures
In-Reply-To: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
Message-ID: <-g6O7flOIAsvPkqqABFpYHwPfAdvVk0bq5B2NWNUEHU=.c899e648-85cf-4202-a331-289c225e8675@github.com>

On Thu, 25 Aug 2022 08:02:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).

I adjusted the return syntax.

-------------

PR: https://git.openjdk.org/jdk/pull/10015


From aghaisas at openjdk.org  Fri Aug 26 10:49:55 2022
From: aghaisas at openjdk.org (Ajit Ghaisas)
Date: Fri, 26 Aug 2022 10:49:55 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline [v2]
In-Reply-To: <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
 <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>
Message-ID: <WZS3RpMNTBl_r1sW-oq3BoXE5Na9cnSu3U2Zdm9NM74=.c5365608-4aad-47a3-a580-c1a47faa8798@github.com>

On Wed, 24 Aug 2022 13:37:16 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Reuse displaysync thread for subsequent updates
>
> Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8290344: Start/stop displaysync affects performance in metal rendering pipeline
>   
>   Reuse displaysync thread for subsequent updates

All test runs on x64 and aarch64 are fine.

-------------

Marked as reviewed by aghaisas (Committer).

PR: https://git.openjdk.org/jdk/pull/9512


From aturbanov at openjdk.org  Fri Aug 26 13:33:00 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 26 Aug 2022 13:33:00 GMT
Subject: RFR: 8292280: Unused field 'keyListener' in BasicRadioButtonUI
 [v2]
In-Reply-To: <VSFr0PzV7Xgie_uI9jeDTwb_dLOX0wrpdJ6afoPzCq4=.fb52dd52-a077-4e3a-bb5f-b2951f6e667a@github.com>
References: <IWbq6Zr-IcRpKs5_IQvKnEL-8lEc9OVxS9GrGkA9t38=.126f3214-32d2-4fef-9505-d61f157d22fb@github.com>
 <m5FaWGhdBKPXUyNkSIkCToBUxirQZ5Q1LaF-jIQRiVc=.ac78ad2f-6be1-48c5-8a38-4b11e47ae9fe@github.com>
 <o8HCbCeXAeSvA4lOXtOjQHViiVBFd7ruuICy2a8x0UI=.d6750ed4-e80f-474a-9d08-a8a93ce8f260@github.com>
 <VSFr0PzV7Xgie_uI9jeDTwb_dLOX0wrpdJ6afoPzCq4=.fb52dd52-a077-4e3a-bb5f-b2951f6e667a@github.com>
Message-ID: <WINH2oy5sAenOTvHNOL_OMm7nWcDFZDsGsDJUNC93FI=.13e25ae1-2e59-4726-b14f-633e7ee7f26a@github.com>

On Thu, 25 Aug 2022 19:55:17 GMT, Phil Race <prr at openjdk.org> wrote:

>> I reverted this changes
>
> why ? .. although it seemed they were unused too, it is just that you didn't mention them anywhere and the title doesn't relate to it.

I will try to remove such unused local variables in separate PR

-------------

PR: https://git.openjdk.org/jdk/pull/9832


From aivanov at openjdk.org  Fri Aug 26 13:59:19 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 26 Aug 2022 13:59:19 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v24]
In-Reply-To: <r-TkXoxVEb0Gyjxw18x4e_bp3mIIcBcFHJ69PZVUt_w=.03881b13-dc07-4074-b423-cfba8c7d926e@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <r-TkXoxVEb0Gyjxw18x4e_bp3mIIcBcFHJ69PZVUt_w=.03881b13-dc07-4074-b423-cfba8c7d926e@github.com>
Message-ID: <o_FO9-eshCmZRQfQgV8tuCfvdYviuLVDrySb7g-fD0w=.26ca3665-2ae4-4daa-a4b3-0d430371f26c@github.com>

On Thu, 25 Aug 2022 04:43:58 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments modified and formatToDoubleValue method name renamed

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/sun/swing/FilePane.java line 1200:

> 1198:                 /*
> 1199:                  * This code block is relevant to Linux.
> 1200:                  * File size is displayd up to 1 decimal precision.

Suggestion:

                 * File size is displayed up to 1 decimal precision.

src/java.desktop/share/classes/sun/swing/FilePane.java line 1266:

> 1264:         /**
> 1265:          * Rounds a value to one decimal place. It's used to format
> 1266:          * file size similar to how it's formatted in file managers on Linux.

Does it make sense to add an example?

         * For example, the file size of 1200 bytes is rounded to 1.2 KB.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Aug 26 14:30:10 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 26 Aug 2022 14:30:10 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v25]
In-Reply-To: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
Message-ID: <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>

> JFileChooser - empty file size issue fixed. 
> For empty file, now the size 0 KB.
> Manual Test Case "FileSizeCheck.java" created.

Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:

  Updated as per suggested changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9327/files
  - new: https://git.openjdk.org/jdk/pull/9327/files/1e086cae..8ffcc83a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9327&range=23-24

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/9327.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9327/head:pull/9327

PR: https://git.openjdk.org/jdk/pull/9327


From duke at openjdk.org  Fri Aug 26 14:30:12 2022
From: duke at openjdk.org (Abhishek Kumar)
Date: Fri, 26 Aug 2022 14:30:12 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v24]
In-Reply-To: <o_FO9-eshCmZRQfQgV8tuCfvdYviuLVDrySb7g-fD0w=.26ca3665-2ae4-4daa-a4b3-0d430371f26c@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <r-TkXoxVEb0Gyjxw18x4e_bp3mIIcBcFHJ69PZVUt_w=.03881b13-dc07-4074-b423-cfba8c7d926e@github.com>
 <o_FO9-eshCmZRQfQgV8tuCfvdYviuLVDrySb7g-fD0w=.26ca3665-2ae4-4daa-a4b3-0d430371f26c@github.com>
Message-ID: <3W5J3xyPwrIu2Qz9do51JYTlnSQRzav-9Ju4i8bGGqw=.0d98a4de-a2d4-4da2-aac7-8aaa2c7acdb4@github.com>

On Fri, 26 Aug 2022 13:54:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments modified and formatToDoubleValue method name renamed
>
> src/java.desktop/share/classes/sun/swing/FilePane.java line 1266:
> 
>> 1264:         /**
>> 1265:          * Rounds a value to one decimal place. It's used to format
>> 1266:          * file size similar to how it's formatted in file managers on Linux.
> 
> Does it make sense to add an example?
> 
>          * For example, the file size of 1200 bytes is rounded to 1.2 KB.

I have added the comment.

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From aivanov at openjdk.org  Fri Aug 26 14:42:09 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 26 Aug 2022 14:42:09 GMT
Subject: RFR: 8288882: JFileChooser - empty (0 bytes) file is displayed as
 1 KB [v25]
In-Reply-To: <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
References: <ZMCIUAQLtETfIq2cSV8TPN6ekQBEWSabRA1vPVjnRt8=.aecf2fbc-02cb-42f8-afea-998e7c25eda6@github.com>
 <Qep3yBG39dxx7SuFQ7G0uVBcAJnvbUFuN6a7fKcbsXs=.f7fea131-2b93-4876-8a35-ccf9a38c6c55@github.com>
Message-ID: <1fTMwks2gela1LkisIRRYzbp0fNJpMrcFDMVRHajvXw=.1d31c283-68a8-4e7e-8ea2-ab0453377133@github.com>

On Fri, 26 Aug 2022 14:30:10 GMT, Abhishek Kumar <duke at openjdk.org> wrote:

>> JFileChooser - empty file size issue fixed. 
>> For empty file, now the size 0 KB.
>> Manual Test Case "FileSizeCheck.java" created.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated as per suggested changes

Marked as reviewed by aivanov (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9327


From prr at openjdk.org  Fri Aug 26 18:52:02 2022
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Aug 2022 18:52:02 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttribute accepts
 negative length [v5]
In-Reply-To: <gdG66T9Gd8VPUtr4zeLCqHL9HfFJtFNVZE3Mdq7fqjs=.68f35333-36dc-4460-ae57-5cf15cb64c84@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <gdG66T9Gd8VPUtr4zeLCqHL9HfFJtFNVZE3Mdq7fqjs=.68f35333-36dc-4460-ae57-5cf15cb64c84@github.com>
Message-ID: <rQ7ss4yvicObX2YDCZ-K1X-Zs-z3tzLpYsUCeOYoVv0=.ef3b7b8d-9b07-480f-9a9a-40767b76805a@github.com>

On Thu, 25 Aug 2022 03:27:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated based on review comments

OK but you need to change the title of this PR to match JBS.

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/9830


From shurailine at openjdk.org  Sat Aug 27 00:38:09 2022
From: shurailine at openjdk.org (Alexandre Iline)
Date: Sat, 27 Aug 2022 00:38:09 GMT
Subject: RFR: 8225012: sanity/client/SwingSet/src/ToolTipDemoTest.java fails on
 Windows
Message-ID: <1rb8LBNCEl28QDHvpFScS19N2BP37UKIbc2qyMM33ig=.6957698e-677a-4b5e-bdf1-1f6aa28d4d81@github.com>

Activate the window with a mouse click.
Close tooltip by moving the window out of the component.

Multiple runs have been performed in the CI, totaling 500 runs on each Windows and Mac OS.

While testing the fix, I have discovered that, while this fixes the problem on Mac and Windows, on linux the test is not fully stable. I have created a bug for that and excluded the test on Linux.

-------------

Commit messages:
 - JDK-8225012: sanity/client/SwingSet/src/ToolTipDemoTest.java fails on Windows

Changes: https://git.openjdk.org/jdk/pull/10053/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10053&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8225012
  Stats: 16 lines in 2 files changed: 9 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/10053.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10053/head:pull/10053

PR: https://git.openjdk.org/jdk/pull/10053


From duke at openjdk.org  Sat Aug 27 09:04:04 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Sat, 27 Aug 2022 09:04:04 GMT
Subject: RFR: 8292948: JEditorPane ignores font-size styles in external linked
 css-file
Message-ID: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>

[JDK-8292948] reveals a regression by the fix for [JDK-8257664] (#1759) causing `font-size` declarations from external style sheets to be ignored.

As far as I've traced, the problem is with the `isDefined(CSS.Attribute.FONT_SIZE)` test:

https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2825-L2830

It misses declarations from linked styles via a `resolver` ([`AttributeSet.ResolveAttribute`](https://github.com/openjdk/jdk/blob/b0e0b87891eb81c2b33c1cfa598701b7bd2e5bdf/src/java.desktop/share/classes/javax/swing/text/AttributeSet.java#L187-L191)) attribute that happens to hold the external style sheet rules.  The fix for this would be to move the implied `CSS.Attribute.FONT_SIZE` handling after:

https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2833-L2835

and drop the `isDefined()` test.

[I'll prepare a jtreg test further.]

[JDK-8292948]: https://bugs.openjdk.org/browse/JDK-8292948 "JEditorPane ignores font-size styles in external linked css-file"
[JDK-8257664]: https://bugs.openjdk.org/browse/JDK-8257664 "HTMLEditorKit: Wrong CSS relative font sizes"

-------------

Commit messages:
 - 8292948: Resolve font-size from external/linked styles

Changes: https://git.openjdk.org/jdk/pull/10054/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292948
  Stats: 10 lines in 1 file changed: 5 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10054/head:pull/10054

PR: https://git.openjdk.org/jdk/pull/10054


From duke at openjdk.org  Sat Aug 27 14:06:19 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Sat, 27 Aug 2022 14:06:19 GMT
Subject: RFR: 8292948: JEditorPane ignores font-size styles in external
 linked css-file [v2]
In-Reply-To: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
References: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
Message-ID: <G-BwoX-pFtRbMzABv2kw7GHL11MKughUGshtmgW9wRk=.e4adebed-ba64-4817-8773-02bb9748faf2@github.com>

> [JDK-8292948] reveals a regression by the fix for [JDK-8257664] (#1759) causing `font-size` declarations from external style sheets to be ignored.
> 
> As far as I've traced, the problem is with the `isDefined(CSS.Attribute.FONT_SIZE)` test:
> 
> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2825-L2830
> 
> It misses declarations from linked styles via a `resolver` ([`AttributeSet.ResolveAttribute`](https://github.com/openjdk/jdk/blob/b0e0b87891eb81c2b33c1cfa598701b7bd2e5bdf/src/java.desktop/share/classes/javax/swing/text/AttributeSet.java#L187-L191)) attribute that happens to hold the external style sheet rules.  The fix for this would be to move the implied `CSS.Attribute.FONT_SIZE` handling after:
> 
> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2833-L2835
> 
> and drop the `isDefined()` test.
> 
> [I'll prepare a jtreg test further.]
> 
> [JDK-8292948]: https://bugs.openjdk.org/browse/JDK-8292948 "JEditorPane ignores font-size styles in external linked css-file"
> [JDK-8257664]: https://bugs.openjdk.org/browse/JDK-8257664 "HTMLEditorKit: Wrong CSS relative font sizes"

Stanimir Stamenkov has updated the pull request incrementally with two additional commits since the last revision:

 - 8292948: Add suggested jtreg test
 - 8292948: Update copyright year

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10054/files
  - new: https://git.openjdk.org/jdk/pull/10054/files/287a8ef0..f7b5c903

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10054&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10054&range=00-01

  Stats: 219 lines in 4 files changed: 218 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10054/head:pull/10054

PR: https://git.openjdk.org/jdk/pull/10054


From duke at openjdk.org  Sat Aug 27 17:14:18 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Sat, 27 Aug 2022 17:14:18 GMT
Subject: RFR: 8292948: JEditorPane ignores font-size styles in external
 linked css-file [v2]
In-Reply-To: <G-BwoX-pFtRbMzABv2kw7GHL11MKughUGshtmgW9wRk=.e4adebed-ba64-4817-8773-02bb9748faf2@github.com>
References: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
 <G-BwoX-pFtRbMzABv2kw7GHL11MKughUGshtmgW9wRk=.e4adebed-ba64-4817-8773-02bb9748faf2@github.com>
Message-ID: <9OKyeMjL1tYssm_HCnnyZTVjTPFRjPdqlZqQnv0nouU=.439cd12a-503e-49dc-8171-9f15849b667a@github.com>

On Sat, 27 Aug 2022 14:06:19 GMT, Stanimir Stamenkov <duke at openjdk.org> wrote:

>> [JDK-8292948] reveals a regression by the fix for [JDK-8257664] (#1759) causing `font-size` declarations from external style sheets to be ignored.
>> 
>> As far as I've traced, the problem is with the `isDefined(CSS.Attribute.FONT_SIZE)` test:
>> 
>> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2825-L2830
>> 
>> It misses declarations from linked styles via a `resolver` ([`AttributeSet.ResolveAttribute`](https://github.com/openjdk/jdk/blob/b0e0b87891eb81c2b33c1cfa598701b7bd2e5bdf/src/java.desktop/share/classes/javax/swing/text/AttributeSet.java#L187-L191)) attribute that happens to hold the external style sheet rules.  The fix for this would be to move the implied `CSS.Attribute.FONT_SIZE` handling after:
>> 
>> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2833-L2835
>> 
>> and drop the `isDefined()` test.
>> 
>> [I'll prepare a jtreg test further.]
>> 
>> [JDK-8292948]: https://bugs.openjdk.org/browse/JDK-8292948 "JEditorPane ignores font-size styles in external linked css-file"
>> [JDK-8257664]: https://bugs.openjdk.org/browse/JDK-8257664 "HTMLEditorKit: Wrong CSS relative font sizes"
>
> Stanimir Stamenkov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8292948: Add suggested jtreg test
>  - 8292948: Update copyright year

test/jdk/javax/swing/text/html/StyleSheet/TestExternalCSSFontSize.java line 58:

> 56: 
> 57:     CountDownLatch setUp() throws Exception {
> 58:         File htmlFile = new File("TestExternalCSSFontSize.html");

Not sure if I should better resolve this from the classpath:

Suggestion:

        URL htmlFile = getClass().getResource(getClass().getSimpleName() + ".html");

-------------

PR: https://git.openjdk.org/jdk/pull/10054


From duke at openjdk.org  Sat Aug 27 23:51:00 2022
From: duke at openjdk.org (ScientificWare)
Date: Sat, 27 Aug 2022 23:51:00 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v7]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <clLOMOQh4mnfGchrCRjuSMbCwh0lOHt9TKRz_v6F0RQ=.90e294d7-105b-4d89-99eb-1819b9f031ad@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

ScientificWare has updated the pull request incrementally with one additional commit since the last revision:

   Whitespace Error 
  
  Removes trailing whitespace.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/da6e34f4..d1c39eaf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Aug 28 00:09:11 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 28 Aug 2022 00:09:11 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v8]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <DUk6gBdezBpIPwFhp2pDfwItfUZLI41hacNsVg5iKjA=.a3472c95-2c5f-429c-af17-70f41e91cf48@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

ScientificWare has updated the pull request incrementally with one additional commit since the last revision:

  Returns new Color. RGB functions case insensitive.
  
  Preserves previous behaviors. Each method call creates a new instance of Color.
  RGB functions should be treated as case insensitive.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/d1c39eaf..5a092e3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=06-07

  Stats: 167 lines in 1 file changed: 6 ins; 0 del; 161 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 Aug 28 05:14:08 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Sun, 28 Aug 2022 05:14:08 GMT
Subject: RFR: 8292948: JEditorPane ignores font-size styles in external
 linked css-file [v3]
In-Reply-To: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
References: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
Message-ID: <DdTUT7vC4FVOCZdCPTiEegnyq8vi9uXgLddgU0rCJuo=.9a817522-794d-47a3-923e-540d9cf2d973@github.com>

> [JDK-8292948] reveals a regression by the fix for [JDK-8257664] (#1759) causing `font-size` declarations from external style sheets to be ignored.
> 
> As far as I've traced, the problem is with the `isDefined(CSS.Attribute.FONT_SIZE)` test:
> 
> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2825-L2830
> 
> It misses declarations from linked styles via a `resolver` ([`AttributeSet.ResolveAttribute`](https://github.com/openjdk/jdk/blob/b0e0b87891eb81c2b33c1cfa598701b7bd2e5bdf/src/java.desktop/share/classes/javax/swing/text/AttributeSet.java#L187-L191)) attribute that happens to hold the external style sheet rules.  The fix for this would be to move the implied `CSS.Attribute.FONT_SIZE` handling after:
> 
> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2833-L2835
> 
> and drop the `isDefined()` test.
> 
> [I'll prepare a jtreg test further.]
> 
> [JDK-8292948]: https://bugs.openjdk.org/browse/JDK-8292948 "JEditorPane ignores font-size styles in external linked css-file"
> [JDK-8257664]: https://bugs.openjdk.org/browse/JDK-8257664 "HTMLEditorKit: Wrong CSS relative font sizes"

Stanimir Stamenkov has updated the pull request incrementally with seven additional commits since the last revision:

 - 8292948: Make captureImage() an instance method
   
   Use just the instance editor component.
 - 8292948: Use bigger/different base font than the default
   
   Make potential discrepancies with not resolving the base more obvious.
 - 8292948: Make the setUp(), run/verify() sequence invocation explicit
   
   Simplify overall setup.
 - 8292948: Avoid failing to save image capture when editor == null
   
   The failure to save the image suppresses the original failure.
 - 8292948: Capitalize messages
 - 8292948: Resolve test HTML file from the classpath
   
   Don't rely on the current working directory.
 - 8292948: Adjust @summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10054/files
  - new: https://git.openjdk.org/jdk/pull/10054/files/f7b5c903..c7d8f0b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10054&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10054&range=01-02

  Stats: 69 lines in 3 files changed: 10 ins; 22 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/10054.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10054/head:pull/10054

PR: https://git.openjdk.org/jdk/pull/10054


From duke at openjdk.org  Sun Aug 28 05:21:00 2022
From: duke at openjdk.org (Stanimir Stamenkov)
Date: Sun, 28 Aug 2022 05:21:00 GMT
Subject: RFR: 8292948: JEditorPane ignores font-size styles in external
 linked css-file [v3]
In-Reply-To: <DdTUT7vC4FVOCZdCPTiEegnyq8vi9uXgLddgU0rCJuo=.9a817522-794d-47a3-923e-540d9cf2d973@github.com>
References: <CXQy2fQCcs9PeBtCtUZmEdKhx9le3CQxQQAf564QVTM=.e448a883-d2e3-425d-aaa4-1b9d32431b60@github.com>
 <DdTUT7vC4FVOCZdCPTiEegnyq8vi9uXgLddgU0rCJuo=.9a817522-794d-47a3-923e-540d9cf2d973@github.com>
Message-ID: <VBJa40T0YVpoVckPAxS3kpHeMz7y_gy7vbaI-CSZL8M=.317bce48-a80a-46d1-b37a-5d04ec120d0f@github.com>

On Sun, 28 Aug 2022 05:14:08 GMT, Stanimir Stamenkov <duke at openjdk.org> wrote:

>> [JDK-8292948] reveals a regression by the fix for [JDK-8257664] (#1759) causing `font-size` declarations from external style sheets to be ignored.
>> 
>> As far as I've traced, the problem is with the `isDefined(CSS.Attribute.FONT_SIZE)` test:
>> 
>> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2825-L2830
>> 
>> It misses declarations from linked styles via a `resolver` ([`AttributeSet.ResolveAttribute`](https://github.com/openjdk/jdk/blob/b0e0b87891eb81c2b33c1cfa598701b7bd2e5bdf/src/java.desktop/share/classes/javax/swing/text/AttributeSet.java#L187-L191)) attribute that happens to hold the external style sheet rules.  The fix for this would be to move the implied `CSS.Attribute.FONT_SIZE` handling after:
>> 
>> https://github.com/openjdk/jdk/blob/70b5b3119b2ed032b021a080f34a4fa28d092fb5/src/java.desktop/share/classes/javax/swing/text/html/StyleSheet.java#L2833-L2835
>> 
>> and drop the `isDefined()` test.
>> 
>> [I'll prepare a jtreg test further.]
>> 
>> [JDK-8292948]: https://bugs.openjdk.org/browse/JDK-8292948 "JEditorPane ignores font-size styles in external linked css-file"
>> [JDK-8257664]: https://bugs.openjdk.org/browse/JDK-8257664 "HTMLEditorKit: Wrong CSS relative font sizes"
>
> Stanimir Stamenkov has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - 8292948: Make captureImage() an instance method
>    
>    Use just the instance editor component.
>  - 8292948: Use bigger/different base font than the default
>    
>    Make potential discrepancies with not resolving the base more obvious.
>  - 8292948: Make the setUp(), run/verify() sequence invocation explicit
>    
>    Simplify overall setup.
>  - 8292948: Avoid failing to save image capture when editor == null
>    
>    The failure to save the image suppresses the original failure.
>  - 8292948: Capitalize messages
>  - 8292948: Resolve test HTML file from the classpath
>    
>    Don't rely on the current working directory.
>  - 8292948: Adjust @summary

| Failure (current) | Success |
| - | - |
| ![failure](https://user-images.githubusercontent.com/1247730/187058728-c1705d01-0607-453d-8042-631ea8ba37f0.png) | ![success](https://user-images.githubusercontent.com/1247730/187058741-40a03db5-0a15-48fd-abf9-e30a407d0899.png) |

-------------

PR: https://git.openjdk.org/jdk/pull/10054


From duke at openjdk.org  Sun Aug 28 11:24:12 2022
From: duke at openjdk.org (ExE Boss)
Date: Sun, 28 Aug 2022 11:24:12 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v8]
In-Reply-To: <DUk6gBdezBpIPwFhp2pDfwItfUZLI41hacNsVg5iKjA=.a3472c95-2c5f-429c-af17-70f41e91cf48@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
 <DUk6gBdezBpIPwFhp2pDfwItfUZLI41hacNsVg5iKjA=.a3472c95-2c5f-429c-af17-70f41e91cf48@github.com>
Message-ID: <xCNDg8jUIYkGZr1aZ2oPSOhkQSxiIpvJJorqafQ4BY0=.1f4fb600-0dee-4304-ae81-7987e428bd69@github.com>

On Sun, 28 Aug 2022 00:09:11 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
>> 
>> This is tracked in JBS as 
>> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)
>
> ScientificWare has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Returns new Color. RGB functions case insensitive.
>   
>   Preserves previous behaviors. Each method call creates a new instance of Color.
>   RGB functions should be treated as case insensitive.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 1401:

> 1399:         if (str == null) {
> 1400:             return null;
> 1401:         } else if (str.length() == 0) {

This?can?use [`String.isEmpty()`]:
Suggestion:

        } else if (str.isEmpty()) {


[`String.isEmpty()`]: https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/lang/String.html#isEmpty()

-------------

PR: https://git.openjdk.org/jdk/pull/9825


From duke at openjdk.org  Sun Aug 28 20:29:22 2022
From: duke at openjdk.org (ScientificWare)
Date: Sun, 28 Aug 2022 20:29:22 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v9]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <A5tobLthrDpyBQqPwo_eRtjG-sl9lAZPDcVs3xQ-chc=.e3c89b12-9115-4dbe-ba1c-2757815d7665@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

ScientificWare has updated the pull request incrementally with one additional commit since the last revision:

  Unused import and String.isEmpty()
  
  1. Removes `TreeMap` unused import.
  1. Replaces `str.length() == 0` with `str.isEmpty()`.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/5a092e3f..0ccaaaee

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=07-08

  Stats: 2 lines in 1 file changed: 0 ins; 1 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 tr at openjdk.org  Mon Aug 29 04:05:11 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 29 Aug 2022 04:05:11 GMT
Subject: RFR: 8291792: DefaultStyledDocument.setCharacterAttributes accepts
 negative length [v5]
In-Reply-To: <rQ7ss4yvicObX2YDCZ-K1X-Zs-z3tzLpYsUCeOYoVv0=.ef3b7b8d-9b07-480f-9a9a-40767b76805a@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
 <gdG66T9Gd8VPUtr4zeLCqHL9HfFJtFNVZE3Mdq7fqjs=.68f35333-36dc-4460-ae57-5cf15cb64c84@github.com>
 <rQ7ss4yvicObX2YDCZ-K1X-Zs-z3tzLpYsUCeOYoVv0=.ef3b7b8d-9b07-480f-9a9a-40767b76805a@github.com>
Message-ID: <Y1nf4wNVwx_wcPf1CJFGMTYuHJ1UrRAqYIFpAXMj0kc=.ab09b182-b578-427d-bb10-3dec9d0b59a9@github.com>

On Fri, 26 Aug 2022 18:49:52 GMT, Phil Race <prr at openjdk.org> wrote:

> OK but you need to change the title of this PR to match JBS.

Sure.....

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From tr at openjdk.org  Mon Aug 29 05:18:06 2022
From: tr at openjdk.org (Tejesh R)
Date: Mon, 29 Aug 2022 05:18:06 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
Message-ID: <emqtvOZPj2td09zCCbD_A4wkcekq_SzV7Hrd_yESJYk=.36e0d3a2-b1df-4f15-a230-507a1a80fc5f@github.com>

On Fri, 19 Aug 2022 23:47:49 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
> 
> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
> 
> The test is generic though the issue and fix is on Windows platform because the condition 
> `frame.getSize() == frame.getPreferredSize()` should be true all platforms when frame.pack() is called.

src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1413:

> 1411:     {
> 1412:         /* This window hasn't been sized yet -- use system metrics. */
> 1413:         jobject target = GetTarget(env);

Moving the declaration and deletion of `target` out of `if` block was on purpose? Any particular reason related to the issue?

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From jdv at openjdk.org  Mon Aug 29 07:25:59 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 29 Aug 2022 07:25:59 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline [v2]
In-Reply-To: <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
 <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>
Message-ID: <Qz9wDVACEJGZ09MwsvELl2oPwERVsgDjdy9SrSsqZ9c=.62a4ff74-66f6-4668-b253-a4d38e9d1cf7@github.com>

On Wed, 24 Aug 2022 13:37:16 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Reuse displaysync thread for subsequent updates
>
> Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8290344: Start/stop displaysync affects performance in metal rendering pipeline
>   
>   Reuse displaysync thread for subsequent updates

Stopping DisplayLink once we are done with blitting was used to fix https://bugs.openjdk.org/browse/JDK-8259038 . I think with displayLink active count as 4 we might see unnecessary(~4) displayLink callbacks when we just draw text and leave it as noticed in the bug.  But i think this tradeoff is fine as we are trying to achieve balance between power and performance.

Also this change should not cause state management issues as we are just maintaining displayLink for longer time. @avu Could you please verify that we are not seeing issues like https://bugs.openjdk.org/browse/JDK-8247332 ?

-------------

PR: https://git.openjdk.org/jdk/pull/9512


From mbaesken at openjdk.org  Mon Aug 29 07:51:13 2022
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 29 Aug 2022 07:51:13 GMT
Subject: RFR: JDK-8292866:
 Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation check MultiByteToWideChar
 return value for failures [v2]
In-Reply-To: <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
References: <prlZNHespV4sJHeN-XKbLbDg5MIXWigO8OS5F03Fcy8=.186655cf-7fc6-41c0-aa6b-3602fae9ca01@github.com>
 <lI4kmR6aNZL2iuCY9Qfe93XtrF8sry7ZgjCspBW8gGg=.656cb9a7-aa39-4f39-9b54-ba91a34ada60@github.com>
Message-ID: <6LcFnjEKvsRvkvogUyk5NKWS4sSdxI00FsiBoYWeaVo=.28aca062-1b25-48b5-a682-0eceda998127@github.com>

On Fri, 26 Aug 2022 07:54:24 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> https://docs.microsoft.com/en-us/windows/win32/api/stringapiset/nf-stringapiset-multibytetowidechar
>> states about MultiByteToWideChar : "The function returns 0 if it does not succeed" and lists a few failure cases.
>> However we miss checking the failure case in Java_sun_awt_shell_Win32ShellFolder2_getLinkLocation , seems we assume the function always works nicely (in most of the JDK coding the return value is checked ).
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust added return syntax

Hi Phil are you fine with the latest revision?

-------------

PR: https://git.openjdk.org/jdk/pull/10015


From psadhukhan at openjdk.org  Mon Aug 29 11:02:34 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 29 Aug 2022 11:02:34 GMT
Subject: Integrated: 7189422: [macosx] Submenu's arrow have a wrong position
In-Reply-To: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
References: <t_YiDB6hvVz8qqYScfG28hHyneLW9SHpyrH72dHrZ-k=.5c84c44f-65be-4bd6-b72d-d8bd5b7dcefb@github.com>
Message-ID: <tLX9QtgFKA-8zXQ8Ak2L4sYUEAg8bkqRgCHe3Dmcmak=.e930fef1-a030-426d-b98d-87e959223136@github.com>

On Fri, 5 Aug 2022 08:58:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is Arrow in submenu with empty title have a wrong position in Aqua L&F as can be seen
> 
> <img width="94" alt="image" src="https://user-images.githubusercontent.com/43534309/183023538-de8e51b4-31e6-45d7-b2bd-35da5e29c1e8.png">
> 
> 
> which is because the text being null/empty, `labelR` rectangle width/height is 0 so arrowIcon y coordinate becomes -ve as per the calculation in layoutMenuItem(). Although it seems logical to me to not show the arrow if submenu text is null, but
> whereas for other L&F, it is shown as this 
> for Metal
> <img width="83" alt="image" src="https://user-images.githubusercontent.com/43534309/183022436-d9e8ebf1-98de-4cf6-bf43-3713357846e5.png">
> 
> for Nimbus
> <img width="77" alt="image" src="https://user-images.githubusercontent.com/43534309/183022730-35d170b2-71c6-4231-9a03-880107dc49c6.png">
> 
> so the fix is made in Aqua L&F to show as other L&F as
> <img width="92" alt="image" src="https://user-images.githubusercontent.com/43534309/183023030-7356086d-957c-4e0d-bd52-bdf3493a96b0.png">

This pull request has now been integrated.

Changeset: d5167a91
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5167a91a9d35afba1a2f246f9d320f1cbb998b2
Stats:     122 lines in 2 files changed: 119 ins; 2 del; 1 mod

7189422: [macosx] Submenu's arrow have a wrong position

Reviewed-by: prr, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/9769


From aivanov at openjdk.org  Mon Aug 29 12:18:08 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 29 Aug 2022 12:18:08 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <emqtvOZPj2td09zCCbD_A4wkcekq_SzV7Hrd_yESJYk=.36e0d3a2-b1df-4f15-a230-507a1a80fc5f@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <emqtvOZPj2td09zCCbD_A4wkcekq_SzV7Hrd_yESJYk=.36e0d3a2-b1df-4f15-a230-507a1a80fc5f@github.com>
Message-ID: <xtbeH5XvrFVsu1CVOViOdfdUw-wWXJmJKwNoDqpqIkk=.54cd7b78-257b-4b26-a9c7-1238b04e23af@github.com>

On Mon, 29 Aug 2022 04:47:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> On Windows, the insets obtained for a Non-Resizable AWT Frame was different when frame.pack() was called and subsequent call to frame.getInsets() or frame.getPreferredSize(). Due to this, the actual and preferred size differed when frame.pack() was called for Non-Resizable frame (on Windows).  
>> 
>> Earlier the insets returned when frame.getInsets() was called, was that of a Resizable frame and not the correct insets associated with Non-Resizable frame. Fix is added to native code to get the correct insets. The test - AwtFramePackTest.java has been updated to test actual and expected/preferred size for both Resizable and Non-Resizable Frames.
>> 
>> The test is generic though the issue and fix is on Windows platform because the condition 
>> `frame.getSize() == frame.getPreferredSize()` should be true all platforms when frame.pack() is called.
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1413:
> 
>> 1411:     {
>> 1412:         /* This window hasn't been sized yet -- use system metrics. */
>> 1413:         jobject target = GetTarget(env);
> 
> Moving the declaration and deletion of `target` out of `if` block was on purpose? Any particular reason related to the issue?

It's used in the condition of the `if`-block.

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From duke at openjdk.org  Mon Aug 29 14:24:59 2022
From: duke at openjdk.org (ScientificWare)
Date: Mon, 29 Aug 2022 14:24:59 GMT
Subject: RFR: JDK-8292276 : Missing color names in CSS. [v10]
In-Reply-To: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
References: <NxusXe1pupY7IAZES-E0ZTmmsgjNaOjB5B6T34pdoOc=.47255159-6050-49a0-911b-c50eaa8253e9@github.com>
Message-ID: <3K40K0Roy0-H5dqJr4TqChwOOCRbEQYnsezkiKe3gEw=.6a48b650-6421-4b32-abc9-f1543b554ac9@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8292276 : Missing color names in CSS](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8292276)
> 
> This is tracked in JBS as 
> - [JDK-8292276 : Missing color names in CSS](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 : Missing color names in CSS](https://github.com/scientificware/jdk/issues/12)

ScientificWare has updated the pull request incrementally with one additional commit since the last revision:

  Adds transparent and RGB case insensitive tests.
  
  When <rgb()> and <rgba()> values contains at least an uppercase character, getAttribute returns null.
  When using 'transparent' keyword getAttribute returns null.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9825/files
  - new: https://git.openjdk.org/jdk/pull/9825/files/0ccaaaee..23416aaa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9825&range=08-09

  Stats: 48 lines in 1 file changed: 38 ins; 0 del; 10 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 alexey.ushakov at jetbrains.com  Mon Aug 29 17:33:10 2022
From: alexey.ushakov at jetbrains.com (Alexey Ushakov)
Date: Mon, 29 Aug 2022 19:33:10 +0200
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline [v2]
In-Reply-To: <Qz9wDVACEJGZ09MwsvELl2oPwERVsgDjdy9SrSsqZ9c=.62a4ff74-66f6-4668-b253-a4d38e9d1cf7@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
 <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>
 <Qz9wDVACEJGZ09MwsvELl2oPwERVsgDjdy9SrSsqZ9c=.62a4ff74-66f6-4668-b253-a4d38e9d1cf7@github.com>
Message-ID: <EE1207F4-CC33-42AE-B482-B0A6C2066E77@jetbrains.com>



> 
> Stopping DisplayLink once we are done with blitting was used to fix https://bugs.openjdk.org/browse/JDK-8259038 . I think with displayLink active count as 4 we might see unnecessary(~4) displayLink callbacks when we just draw text and leave it as noticed in the bug.  But i think this tradeoff is fine as we are trying to achieve balance between power and performance.
> 
> Also this change should not cause state management issues as we are just maintaining displayLink for longer time. @avu Could you please verify that we are not seeing issues like https://bugs.openjdk.org/browse/JDK-8247332 ?

I?ve checked the scenario from JDK-8247332 - everything works as expected.

Best Regards,
Alexey

> 
> -------------
> 
> PR: https://git.openjdk.org/jdk/pull/9512



From jdv at openjdk.org  Tue Aug 30 04:54:18 2022
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 30 Aug 2022 04:54:18 GMT
Subject: RFR: 8290344: Start/stop displaysync affects performance in metal
 rendering pipeline [v2]
In-Reply-To: <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
 <VWhd5TxoG5HWaWOInViSaMHjxLr1AVIWo8ZcaLOgEtg=.95b8bbc7-20a9-49e7-9023-d7798c9605c8@github.com>
Message-ID: <pPzNblUriwdIh-iTIcudMFv44pgP0U8__vw1J_XPbBY=.0a7306a2-6928-439d-8c72-f88c866d5d8e@github.com>

On Wed, 24 Aug 2022 13:37:16 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Reuse displaysync thread for subsequent updates
>
> Alexey Ushakov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8290344: Start/stop displaysync affects performance in metal rendering pipeline
>   
>   Reuse displaysync thread for subsequent updates

Marked as reviewed by jdv (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/9512


From tr at openjdk.org  Tue Aug 30 06:59:08 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 30 Aug 2022 06:59:08 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <xtbeH5XvrFVsu1CVOViOdfdUw-wWXJmJKwNoDqpqIkk=.54cd7b78-257b-4b26-a9c7-1238b04e23af@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <emqtvOZPj2td09zCCbD_A4wkcekq_SzV7Hrd_yESJYk=.36e0d3a2-b1df-4f15-a230-507a1a80fc5f@github.com>
 <xtbeH5XvrFVsu1CVOViOdfdUw-wWXJmJKwNoDqpqIkk=.54cd7b78-257b-4b26-a9c7-1238b04e23af@github.com>
Message-ID: <AxPkkAZJluasZ_pykt-84iJILrRykLrmjTWDf8eyfys=.74a2a082-b548-4023-a460-0f8b65dbb3e9@github.com>

On Mon, 29 Aug 2022 12:14:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 1413:
>> 
>>> 1411:     {
>>> 1412:         /* This window hasn't been sized yet -- use system metrics. */
>>> 1413:         jobject target = GetTarget(env);
>> 
>> Moving the declaration and deletion of `target` out of `if` block was on purpose? Any particular reason related to the issue?
>
> It's used in the condition of the `if`-block.

It could have been declared, initialized and deleted inside the if block right......?

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From avu at openjdk.org  Tue Aug 30 08:26:54 2022
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 30 Aug 2022 08:26:54 GMT
Subject: Integrated: 8290344: Start/stop displaysync affects performance in
 metal rendering pipeline
In-Reply-To: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
References: <swItXvagj2hb2MiWL3ZH8V839dt2Ff4ZfA49lIL6vl8=.7d65e095-f4ff-42e7-9fca-4ddd65bc1912@github.com>
Message-ID: <ZFnNMP8p8Oi8Nnn0p7M7Xy30DhxoKeVncvHnsp2EZ_I=.cf08999e-c3ae-49b6-8284-6e6f8d58cb96@github.com>

On Fri, 15 Jul 2022 11:32:20 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

> Reuse displaysync thread for subsequent updates

This pull request has now been integrated.

Changeset: f766d927
Author:    Alexey Ushakov <avu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f766d92755276a40f0cdc087db32c285548572fe
Stats:     22 lines in 2 files changed: 15 ins; 0 del; 7 mod

8290344: Start/stop displaysync affects performance in metal rendering pipeline

Reviewed-by: aghaisas, jdv

-------------

PR: https://git.openjdk.org/jdk/pull/9512


From tr at openjdk.org  Tue Aug 30 08:41:11 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 30 Aug 2022 08:41:11 GMT
Subject: Integrated: 8291792: DefaultStyledDocument.setCharacterAttributes
 accepts negative length
In-Reply-To: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
References: <tD9_E5FTn03eDKxH-AojI-r94kg0k9McKQk7V4GrmH4=.35da4bfe-17c4-4c7a-a404-6c14245ab608@github.com>
Message-ID: <TAIIjRliklgc0_s0uZD35AYtNEUKGaf1W7dwxRixMxU=.4ad8b7ad-7060-4803-bed7-232109c29e9d@github.com>

On Thu, 11 Aug 2022 05:21:48 GMT, Tejesh R <tr at openjdk.org> wrote:

> The Document for _DefaultStyledDocument.setCharacterAttribute_ states that the range of length accepted is `length - the length >= 0`, whereas in code the length check is done only for `length==0`. Meaning the control just returns if the `length` is 0. Since length is  _int_ type and there is a possibility of negative length being set through the method, the code doesn't actually handles the negative length case. Hence to handle negative length, negative length check has been added along with 0 check. Its safe to check and return the control for `negative` length input. Test case to check the same is added.

This pull request has now been integrated.

Changeset: 4a28f379
Author:    Tejesh R <tr at openjdk.org>
Committer: Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4a28f3798d25b64d44aad557f94d1045c253cdfb
Stats:     99 lines in 2 files changed: 97 ins; 0 del; 2 mod

8291792: DefaultStyledDocument.setCharacterAttributes accepts negative length

Reviewed-by: psadhukhan, prr

-------------

PR: https://git.openjdk.org/jdk/pull/9830


From aturbanov at openjdk.org  Tue Aug 30 10:25:55 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 30 Aug 2022 10:25:55 GMT
Subject: Integrated: 8292850: Unused field 'expiredTimersKey' in
 javax.swing.TimerQueue
In-Reply-To: <6AJdh0g0NneBzT3eDifux9zAt-Wm5XQiavZBpET2HEI=.f9675095-5b0c-473f-8811-ec88533d227c@github.com>
References: <6AJdh0g0NneBzT3eDifux9zAt-Wm5XQiavZBpET2HEI=.f9675095-5b0c-473f-8811-ec88533d227c@github.com>
Message-ID: <ntiPp2JyDV3kYhylQ-KmuiJKfiG98ast4bkzez40NKU=.5b5021ce-db4b-4033-8ed5-abd9e262c67f@github.com>

On Wed, 24 Aug 2022 18:05:40 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 8292850: Unused field 'expiredTimersKey' in javax.swing.TimerQueue

This pull request has now been integrated.

Changeset: b3450e93
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b3450e930e52f03ffc3891de7672625ac45b13d0
Stats:     9 lines in 1 file changed: 0 ins; 7 del; 2 mod

8292850: Unused field 'expiredTimersKey' in javax.swing.TimerQueue

Reviewed-by: prr

-------------

PR: https://git.openjdk.org/jdk/pull/10001


From djelinski at openjdk.org  Tue Aug 30 12:26:02 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 30 Aug 2022 12:26:02 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio preprocessor
Message-ID: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>

Fix compilation with Zc:preprocessor enabled. 

The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.

Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.

I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

-------------

Commit messages:
 - Improve standards compliance

Changes: https://git.openjdk.org/jdk/pull/10080/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10080&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293088
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/10080.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10080/head:pull/10080

PR: https://git.openjdk.org/jdk/pull/10080


From psadhukhan at openjdk.org  Tue Aug 30 12:46:47 2022
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 30 Aug 2022 12:46:47 GMT
Subject: RFR: 5074006: Swing JOptionPane shows </html> tag as a string after
 newline
Message-ID: <DWhqieaffzn6xk--zvJwqX4LVNFtVnuI-5rnfuFGTL0=.55ec4218-3188-4917-9233-cbce1562f3e2@github.com>

If JOptionPane's message content both linefeed/cursor return and HTML tag, "</html\>" will be shown in the JOptionPane dialog box because after every new line it creates a new messageComponent so the characters after the newline ie html tag will be considered as a new JLabel string and displayed.
Fix is to ignore closing html tag if appearing after newline from the displayed string.

-------------

Commit messages:
 - Fix
 - 5074006: Swing JOptionPane shows <html> tag as a string after newline

Changes: https://git.openjdk.org/jdk/pull/10081/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-5074006
  Stats: 74 lines in 2 files changed: 71 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10081.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10081/head:pull/10081

PR: https://git.openjdk.org/jdk/pull/10081


From aivanov at openjdk.org  Tue Aug 30 13:41:08 2022
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 30 Aug 2022 13:41:08 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <AxPkkAZJluasZ_pykt-84iJILrRykLrmjTWDf8eyfys=.74a2a082-b548-4023-a460-0f8b65dbb3e9@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <emqtvOZPj2td09zCCbD_A4wkcekq_SzV7Hrd_yESJYk=.36e0d3a2-b1df-4f15-a230-507a1a80fc5f@github.com>
 <xtbeH5XvrFVsu1CVOViOdfdUw-wWXJmJKwNoDqpqIkk=.54cd7b78-257b-4b26-a9c7-1238b04e23af@github.com>
 <AxPkkAZJluasZ_pykt-84iJILrRykLrmjTWDf8eyfys=.74a2a082-b548-4023-a460-0f8b65dbb3e9@github.com>
Message-ID: <EgwlMNYEh4lSo_qHHtRONb0h0NtsedCBkTg0QRnWW9c=.452b20e9-e003-49c7-a1a0-44e79be1454e@github.com>

On Tue, 30 Aug 2022 06:57:05 GMT, Tejesh R <tr at openjdk.org> wrote:

>> It's used in the condition of the `if`-block.
>
> It could have been declared, initialized and deleted inside the if block right......?

It was before. Now the `if`-condition uses `target` object:

if (... || JNU_IsInstanceOfByName(env, target, "java/awt/Frame") > 0)

Thus, the `target` object must be declared and initialised outside of the `if`-block.

Previously, it was used inside only, for this reason it was declared and disposed of inside the `if`-block.

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From tr at openjdk.org  Tue Aug 30 14:22:18 2022
From: tr at openjdk.org (Tejesh R)
Date: Tue, 30 Aug 2022 14:22:18 GMT
Subject: RFR: 8288325: [windows] Actual and Preferred Size of AWT
 Non-resizable frame are different
In-Reply-To: <EgwlMNYEh4lSo_qHHtRONb0h0NtsedCBkTg0QRnWW9c=.452b20e9-e003-49c7-a1a0-44e79be1454e@github.com>
References: <XvPC_1ItEEnbvUPDCLWKDLy7DQ7iGko2xo2DI9777MI=.a5d55959-31e6-4b70-8630-f14c1140134c@github.com>
 <emqtvOZPj2td09zCCbD_A4wkcekq_SzV7Hrd_yESJYk=.36e0d3a2-b1df-4f15-a230-507a1a80fc5f@github.com>
 <xtbeH5XvrFVsu1CVOViOdfdUw-wWXJmJKwNoDqpqIkk=.54cd7b78-257b-4b26-a9c7-1238b04e23af@github.com>
 <AxPkkAZJluasZ_pykt-84iJILrRykLrmjTWDf8eyfys=.74a2a082-b548-4023-a460-0f8b65dbb3e9@github.com>
 <EgwlMNYEh4lSo_qHHtRONb0h0NtsedCBkTg0QRnWW9c=.452b20e9-e003-49c7-a1a0-44e79be1454e@github.com>
Message-ID: <TstTSHeZ2zctS-FdiE2AbLgdthfF4rybqJh2PJ71XAg=.ebae0f4a-7299-4449-924c-adf100fe7b86@github.com>

On Tue, 30 Aug 2022 13:39:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It could have been declared, initialized and deleted inside the if block right......?
>
> It was before. Now the `if`-condition uses `target` object:
> 
> if (... || JNU_IsInstanceOfByName(env, target, "java/awt/Frame") > 0)
> 
> Thus, the `target` object must be declared and initialised outside of the `if`-block.
> 
> Previously, it was used inside only, for this reason it was declared and disposed of inside the `if`-block.

Yeah, I didn't notice` JNU_IsInstanceOfByName(`) called in `if` condition...... Got it.....

-------------

PR: https://git.openjdk.org/jdk/pull/9954


From ihse at openjdk.org  Tue Aug 30 15:03:19 2022
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 30 Aug 2022 15:03:19 GMT
Subject: RFR: 8293088: Fix compilation with the new Visual Studio
 preprocessor
In-Reply-To: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
References: <XVEAYqOYQbX2OKeFBgssCKa5tmiVwG6UPbFIl5SUiLg=.2c502946-199e-4d16-a9be-5e09338707e8@github.com>
Message-ID: <iYq1YSL2DHOKxf4o_dmgqwmECT9tyJWN11eVb2kmnhI=.936762b0-bd3a-4fa7-ae54-93c75cadc913@github.com>

On Tue, 30 Aug 2022 12:08:09 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Fix compilation with Zc:preprocessor enabled. 
> 
> The flag itself will be enabled in [JDK-8247283](https://bugs.openjdk.org/browse/JDK-8247283); I enabled the flag using instructions found in Magnus's comment on that issue.
> 
> Windows 10 SDK version 2104 (10.0.20348.0) is required for successful compilation. Compilation fails with a warning (treated as error by default) with older versions of Windows 10 SDK.
> 
> I verified that the compilation completes successfully with this patch, both in debug and in release mode, both with and without Zc:preprocessor.

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/10080


From asemenov at openjdk.org  Wed Aug 31 07:46:13 2022
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 Aug 2022 07:46:13 GMT
Subject: RFR: 8271846 a11y API lacks setSelectedIndex method [v2]
In-Reply-To: <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
References: <iogsScwXVmrG-QaPPqnBIyBbyc30OmKOUPLjiSKpEEs=.c76d3e64-ea3e-4560-a88a-821f25f9680b@github.com>
 <UfBh-sr7FlTUWKOsVoL1_t28GUxWp3WRrVgxJ9gYSfw=.44b84613-dc9c-49db-add7-8c96047ef9ee@github.com>
Message-ID: <-SB0xU0t4E4T1E3ZuDIHyxQyjhDMqLToxjUilRRK0q4=.45423896-e355-474e-ba6b-9f9ef8917bfd@github.com>

On Wed, 11 May 2022 12:49:34 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 don't do @author tags in openjdk
>   Not 2022 ?

@azuev-java @mrserb @prrace please review [CSR](https://bugs.openjdk.org/browse/JDK-8286674 "[bugs.openjdk.org](http://bugs.openjdk.org/)") and this PR.

-------------

PR: https://git.openjdk.org/jdk/pull/8578


From aturbanov at openjdk.org  Wed Aug 31 09:00:40 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 09:00:40 GMT
Subject: RFR: 8293159: Use try-with-resources in X11FontManager.registerFontDir
Message-ID: <05z0cNBF7JPLVHQGt0B5WBYiZIXwgEey8XEsWG9yCYg=.9ef77c92-2ef1-4e23-ad44-15da001a4a05@github.com>

Makes code easier to read.

-------------

Commit messages:
 - [PATCH] Use try-with-resources in X11FontManager.registerFontDir

Changes: https://git.openjdk.org/jdk/pull/9879/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9879&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293159
  Stats: 164 lines in 1 file changed: 45 ins; 55 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/9879.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9879/head:pull/9879

PR: https://git.openjdk.org/jdk/pull/9879


From dnguyen at openjdk.org  Wed Aug 31 17:53:10 2022
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 31 Aug 2022 17:53:10 GMT
Subject: RFR: 8054572: [macosx] JComboBox paints the border incorrectly
 [v7]
In-Reply-To: <fLdwg5tf1pNBBPZjaC4kPq8rAR2wR6o61uJj0JPNk6w=.8dae6d77-f220-4c5a-9904-0b77465fd308@github.com>
References: <-qF2JbwHypKtIsUXDE-lb7efmsC8-_jTjR_VrPYS_44=.514a5514-f2c1-4fa6-8b83-40f476660f5c@github.com>
 <qay_twnp4S2mtoyFXNfTAxWJuMmiK4eZrK1MKdvBUgA=.b614b959-f157-4b90-bbce-e1626474e15c@github.com>
 <fLdwg5tf1pNBBPZjaC4kPq8rAR2wR6o61uJj0JPNk6w=.8dae6d77-f220-4c5a-9904-0b77465fd308@github.com>
Message-ID: <CMda7n-jNPE4l-ardt65Ip4yS3uJGNjkrkdEC_JoEKo=.f52c18fa-e58f-4182-9a59-6bf5eb38bc3b@github.com>

On Fri, 26 Aug 2022 07:39:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright date. Added MacOS text to test.
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 471:
> 
>> 469: 
>> 470:             if (comboBox.getComponentOrientation().isLeftToRight()) {
>> 471:                 return new Rectangle(insets.left, insets.top + midHeight,
> 
> OK. Since Apple has confirmed combobox height shouldn't change with font size, we can have fixed height.
> 
> Only thing I guess, till we sort out JDK-8023912: [macosx] JComboBox RTL orientation problem
> lets use LTR as it seems it might give a false impression that we support RTL when we dont even know if Apple supports it or not. Do you see any difference with combobox if you use LTR code vs RTL code with RTL testcase present in the above JBS? I dont in my BigSur.
> 
> It will also be good to test it out in non-retina display to see if this "22" height is being shown ok there.

I don't see a difference either but was following the same logic as used in BasicComboBoxUI. I can remove the LTR vs RTL logic until the other issue is resolved if needed.

-------------

PR: https://git.openjdk.org/jdk/pull/9473