From dnguyen at openjdk.org  Wed Nov  1 00:27:07 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 1 Nov 2023 00:27:07 GMT
Subject: RFR: 8316028: Update FreeType to 2.13.2
In-Reply-To: <RQQ6lzVIhKuGStz0kHQzuxmj9ShxPQTGgX641XZ1ykI=.21e5d445-415f-4c51-8fc8-4cd116572c70@github.com>
References: <RQQ6lzVIhKuGStz0kHQzuxmj9ShxPQTGgX641XZ1ykI=.21e5d445-415f-4c51-8fc8-4cd116572c70@github.com>
Message-ID: <hmtOC2q-9Nt_LiJFQZgdaHgu0AaYdtD1ZxKk5fCcgus=.4fb820fe-125a-4c7a-99e6-bed085e60e85@github.com>

On Thu, 26 Oct 2023 21:45:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updating freetype
> mach5 build is green

LGTM

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16385#pullrequestreview-1707406858

From djelinski at openjdk.org  Wed Nov  1 09:15:25 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 1 Nov 2023 09:15:25 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
Message-ID: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>

hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.

The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.

Client libs tests continue to pass.

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

Commit messages:
 - Add comment
 - Do not compile hb-subset files

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

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

From erikj at openjdk.org  Wed Nov  1 13:10:01 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 1 Nov 2023 13:10:01 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <H0mmGgTnAEiMBJt8z1Uj3_z9XSTx2eoBlAX7h5tIOKU=.aca9f710-6dc0-4f70-babf-2096676e1d40@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

This looks good to me from a build point of view, but needs someone from client to approve as well.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16440#pullrequestreview-1708185949

From aivanov at openjdk.org  Wed Nov  1 15:30:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 1 Nov 2023 15:30:16 GMT
Subject: Integrated: 8316025: Use testUI() method of PassFailJFrame.Builder in
 FileChooserSymLinkTest.java
In-Reply-To: <TZK6o_XotANAvIBx5_9eHaJEI7AShYXPiBkdf6RKivg=.ed66abb0-5281-463c-bccd-ed674e3bf7e1@github.com>
References: <TZK6o_XotANAvIBx5_9eHaJEI7AShYXPiBkdf6RKivg=.ed66abb0-5281-463c-bccd-ed674e3bf7e1@github.com>
Message-ID: <-Rt0CuyjF4-z-zcNPF28IpJedoGySWd7-l9YZR5J13I=.6767cbd4-7811-43ea-81bc-0c115536534f@github.com>

On Mon, 11 Sep 2023 16:54:10 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This update to `FileChooserSymLinkTest.java` demonstrates the usage of the `testUI` method of the `PassFailJFrame.Builder` class to streamline creating the UI for manual tests.
> 
> The [`main` method](https://github.com/aivanov-jdk/jdk/blob/cb1835527d718226f1c6fdd85ff5986703ea356f/test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java#L110-L118) is a simple sequence of calls:
> 
> 
>     public static void main(String[] args) throws Exception {
>         PassFailJFrame.builder()
>                       .instructions(INSTRUCTIONS)
>                       .rows(35)
>                       .columns(50)
>                       .testUI(FileChooserSymLinkTest::createTestUI)
>                       .build()
>                       .awaitAndCheck();
>     }
> 
> 
> It's the most streamlined way of creating a manual test.
> 
> This change depends on #15665 and [JDK-8294156](https://bugs.openjdk.org/browse/JDK-8294156) as well as #15661, both of which depend on #15660.

This pull request has now been integrated.

Changeset: 7f47c51a
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f47c51aced9c724dbc9b0d8cbd88c49435da460
Stats:     123 lines in 1 file changed: 53 ins; 60 del; 10 mod

8316025: Use testUI() method of PassFailJFrame.Builder in FileChooserSymLinkTest.java

Reviewed-by: azvegint

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

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

From aivanov at openjdk.org  Wed Nov  1 18:44:03 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 1 Nov 2023 18:44:03 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <QWUDwqTqtkiW7_voF_-niOK8JofC0S2WVMqS2cTGNHc=.5bc773ac-169d-44cb-8d69-9bb3f52086f5@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

Looks good to me.

You may want to wait for Phil's approval though.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16440#pullrequestreview-1708815489

From prr at openjdk.org  Wed Nov  1 18:55:01 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 1 Nov 2023 18:55:01 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
 <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>
Message-ID: <L3T64FQuUSIrTQvaKgrQIaliuLyGWRWROmsR-2zbJJw=.651a58a0-5015-45d7-97e8-b40361739f7c@github.com>

On Wed, 1 Nov 2023 18:51:26 GMT, Phil Race <prr at openjdk.org> wrote:

>> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
>> 
>> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
>> 
>> Client libs tests continue to pass.
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 499:
> 
>> 497:    LIBFONTMANAGER_EXCLUDE_FILES += hb-ft.cc hb-subset-cff-common.cc \
>> 498:        hb-subset-cff1.cc hb-subset-cff2.cc hb-subset-input.cc hb-subset-plan.cc \
>> 499:        hb-subset.cc hb-subset-instancer-solver.cc gsubgpos-context.cc hb-style.cc
> 
> I'm quite confused from where you got gsubgpos-context.cc. I don't see any file of that name.
> Also I just realised that since the Nov 2020 import of freetype it has a bunch of handly ifdefs that
> you can see in hb-config.h
> And so probably a better way of doing this, even if it means one of these files (the instance-solver one) doesn't seem to get the ifdef treatment is to use the specific defines passed to the build.
> Then I'd expect harfbuzz to apply the same ifdef even if these files got refactored.
> I further noticed that the same 2020 update adds HAVE_FREETYPE and hb-ft.cc isn't compiled unless you actually set that. Which we don't
> So this whole exclude can go away and be replaced by a few -D defines.
> You could probably go overboard and experiment with all sorts of combinations from hb-config.h but I recommend you just apply the minimal set that makes your build time happier.
> hb-style.cc isn't one I'd have realised we don't currently need .. and for many of them it isn't clear to me without research what the consequences would be of excluding it. Without that support would something non-optimal happen in some cases - you can't trust the tests we have to come near proving it.
> I know we don't subset, and that's the only one I consider "safe" to use here without actual research.

These two
#define HB_NO_SUBSET_LAYOUT
#define HB_NO_SUBSET_CFF

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16440#discussion_r1379184282

From prr at openjdk.org  Wed Nov  1 18:55:01 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 1 Nov 2023 18:55:01 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 499:

> 497:    LIBFONTMANAGER_EXCLUDE_FILES += hb-ft.cc hb-subset-cff-common.cc \
> 498:        hb-subset-cff1.cc hb-subset-cff2.cc hb-subset-input.cc hb-subset-plan.cc \
> 499:        hb-subset.cc hb-subset-instancer-solver.cc gsubgpos-context.cc hb-style.cc

I'm quite confused from where you got gsubgpos-context.cc. I don't see any file of that name.
Also I just realised that since the Nov 2020 import of freetype it has a bunch of handly ifdefs that
you can see in hb-config.h
And so probably a better way of doing this, even if it means one of these files (the instance-solver one) doesn't seem to get the ifdef treatment is to use the specific defines passed to the build.
Then I'd expect harfbuzz to apply the same ifdef even if these files got refactored.
I further noticed that the same 2020 update adds HAVE_FREETYPE and hb-ft.cc isn't compiled unless you actually set that. Which we don't
So this whole exclude can go away and be replaced by a few -D defines.
You could probably go overboard and experiment with all sorts of combinations from hb-config.h but I recommend you just apply the minimal set that makes your build time happier.
hb-style.cc isn't one I'd have realised we don't currently need .. and for many of them it isn't clear to me without research what the consequences would be of excluding it. Without that support would something non-optimal happen in some cases - you can't trust the tests we have to come near proving it.
I know we don't subset, and that's the only one I consider "safe" to use here without actual research.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16440#discussion_r1379183503

From djelinski at openjdk.org  Wed Nov  1 21:34:01 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 1 Nov 2023 21:34:01 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <L3T64FQuUSIrTQvaKgrQIaliuLyGWRWROmsR-2zbJJw=.651a58a0-5015-45d7-97e8-b40361739f7c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
 <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>
 <L3T64FQuUSIrTQvaKgrQIaliuLyGWRWROmsR-2zbJJw=.651a58a0-5015-45d7-97e8-b40361739f7c@github.com>
Message-ID: <k_L1TnwIOXAazmC4cPBGkYlYIutMqQj-vVesd-oUrA8=.3234cc6e-5097-4729-bc61-ae0d7c72872e@github.com>

On Wed, 1 Nov 2023 18:52:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 499:
>> 
>>> 497:    LIBFONTMANAGER_EXCLUDE_FILES += hb-ft.cc hb-subset-cff-common.cc \
>>> 498:        hb-subset-cff1.cc hb-subset-cff2.cc hb-subset-input.cc hb-subset-plan.cc \
>>> 499:        hb-subset.cc hb-subset-instancer-solver.cc gsubgpos-context.cc hb-style.cc
>> 
>> I'm quite confused from where you got gsubgpos-context.cc. I don't see any file of that name.
>> Also I just realised that since the Nov 2020 import of freetype it has a bunch of handly ifdefs that
>> you can see in hb-config.h
>> And so probably a better way of doing this, even if it means one of these files (the instance-solver one) doesn't seem to get the ifdef treatment is to use the specific defines passed to the build.
>> Then I'd expect harfbuzz to apply the same ifdef even if these files got refactored.
>> I further noticed that the same 2020 update adds HAVE_FREETYPE and hb-ft.cc isn't compiled unless you actually set that. Which we don't
>> So this whole exclude can go away and be replaced by a few -D defines.
>> You could probably go overboard and experiment with all sorts of combinations from hb-config.h but I recommend you just apply the minimal set that makes your build time happier.
>> hb-style.cc isn't one I'd have realised we don't currently need .. and for many of them it isn't clear to me without research what the consequences would be of excluding it. Without that support would something non-optimal happen in some cases - you can't trust the tests we have to come near proving it.
>> I know we don't subset, and that's the only one I consider "safe" to use here without actual research.
>
> These two
> #define HB_NO_SUBSET_LAYOUT
> #define HB_NO_SUBSET_CFF

You can find the file here:
https://github.com/openjdk/jdk/blob/f262f06c97b9ea94cd6119b3a8beb16bf804d083/src/java.desktop/share/native/libharfbuzz/graph/gsubgpos-context.cc

Hb-subset files are not guarded by ifdefs; HB_NO_SUBSET_LAYOUT only excludes some functions, but not others. I'll check the impact of that define when I'm back in office.

I checked the list of HB APIs [here](https://harfbuzz.github.io/reference-manual.html) ; hb-subset and hb-style belong to non-core API sets, so I decided to check if hb-style was needed. It was not.

We can safely stop compiling the files listed because:
- none of the harfbuzz functions are exported, and they are not accessible outside of libfontmanager.
- if we excluded any file that was actually used, linker would refuse to link libfontmanager

Given that we only copy an arbitrary subset of harfbuzz files anyway (see UPDATING.txt), would it make sense to remove these files instead?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16440#discussion_r1379353297

From duke at openjdk.org  Thu Nov  2 04:34:23 2023
From: duke at openjdk.org (null)
Date: Thu, 2 Nov 2023 04:34:23 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643
Message-ID: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>

Build failure with GCC8.3.1

=== Output from failing command(s) repeated here ===
* For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
/data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
/data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       extents->ascender = max;
       ~~~~~~~~~~~~~~~~~~~^~~~~
/data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
       extents->descender = min;
       ~~~~~~~~~~~~~~~~~~~^~~~~
At global scope:
cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
cc1plus: all warnings being treated as errors

* All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
=== End of repeated output ===

No indication of failed target found.
HELP: Try searching the build log for '] Error'.
HELP: Run 'make doctor' to diagnose build problems.

make[1]: *** [main] Error 1
make: *** [images] Error 2

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

Commit messages:
 - 8319268: Build failure with GCC8.3.1 after 8313643

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

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

From jiefu at openjdk.org  Thu Nov  2 06:57:02 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 2 Nov 2023 06:57:02 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643
In-Reply-To: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
Message-ID: <sL0uWIM0Av3v3CXtfTZfazegVhWzniPVPKdwk42qJeg=.84f494db-625d-4099-b711-c9eda1034ec9@github.com>

On Thu, 2 Nov 2023 04:29:01 GMT, null <duke at openjdk.org> wrote:

> Build failure with GCC8.3.1
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->ascender = max;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->descender = min;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> At global scope:
> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
> cc1plus: all warnings being treated as errors
> 
> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
> === End of repeated output ===
> 
> No indication of failed target found.
> HELP: Try searching the build log for '] Error'.
> HELP: Run 'make doctor' to diagnose build problems.
> 
> make[1]: *** [main] Error 1
> make: *** [images] Error 2

So does it only fail with GCC8?

If so, please add comments for it.
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1790170729

From duke at openjdk.org  Thu Nov  2 07:14:14 2023
From: duke at openjdk.org (null)
Date: Thu, 2 Nov 2023 07:14:14 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
Message-ID: <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>

> Build failure with GCC8.3.1
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->ascender = max;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->descender = min;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> At global scope:
> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
> cc1plus: all warnings being treated as errors
> 
> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
> === End of repeated output ===
> 
> No indication of failed target found.
> HELP: Try searching the build log for '] Error'.
> HELP: Run 'make doctor' to diagnose build problems.
> 
> make[1]: *** [main] Error 1
> make: *** [images] Error 2

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

  add comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16468/files
  - new: https://git.openjdk.org/jdk/pull/16468/files/f316413a..c4f20e30

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

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

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

From jiefu at openjdk.org  Thu Nov  2 07:14:14 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Thu, 2 Nov 2023 07:14:14 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
Message-ID: <wJ4K3Xwxig8aDieR4-AfY7mA43PziK7ZO2S3et0AUNs=.eb240715-f19d-4a37-ad8b-e36773d8d3dc@github.com>

On Thu, 2 Nov 2023 07:11:49 GMT, null <duke at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> null has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

LGTM

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

Marked as reviewed by jiefu (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16468#pullrequestreview-1709578622

From duke at openjdk.org  Thu Nov  2 07:14:16 2023
From: duke at openjdk.org (null)
Date: Thu, 2 Nov 2023 07:14:16 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643
In-Reply-To: <sL0uWIM0Av3v3CXtfTZfazegVhWzniPVPKdwk42qJeg=.84f494db-625d-4099-b711-c9eda1034ec9@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <sL0uWIM0Av3v3CXtfTZfazegVhWzniPVPKdwk42qJeg=.84f494db-625d-4099-b711-c9eda1034ec9@github.com>
Message-ID: <ZGzSq8slSw25W02lPO6yRGC-_v4DJk4I1XzxDfQHfHc=.2359bafe-7bc0-4603-9ac1-26e7395008f5@github.com>

On Thu, 2 Nov 2023 06:54:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> So does it only fail with GCC8?
> 
> If so, please add comments for it.
> Thanks.

@DamonFool 
Thanks for the review.
gcc9 is compiled successfully.I've added comments.
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1790185691

From jwaters at openjdk.org  Thu Nov  2 10:28:34 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 10:28:34 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v10]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <ZsX8D0GCXnMRdxYURQRkg0arqC0HmrJvZ8cs9QjoqoA=.43c26a1e-fc58-4582-87b4-90c18b7db146@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

 - Split into declaration and assignment part one awt_Component.cpp
 - Formatting in awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/1742036e..fdb7f327

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

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

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

From jwaters at openjdk.org  Thu Nov  2 10:32:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 10:32:27 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v11]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <4ork8ZxM7S1wHrPpk3bLnau9eqKsCrvHbEOYrutV-gU=.3239f7e2-dec4-4a4d-8746-a24a2bf9ffd2@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

 - Formatting in awt_Component.cpp
 - Part two awt_Component.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/fdb7f327..d5e5c89b

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

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

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

From jwaters at openjdk.org  Thu Nov  2 10:52:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 10:52:27 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v12]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <LkawUol8ApqyZ9AVsj6MPLMRTbufSaCRFH3s6mxp9ho=.7f64614d-758d-4139-a4d4-7b6d2875993e@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

Julian Waters has updated the pull request incrementally with three additional commits since the last revision:

 - Formatting part two awt_Frame.cpp
 - Formatting awt_Frame.cpp
 - Split in awt_Frame.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/d5e5c89b..7ac6bfe3

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

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

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

From jwaters at openjdk.org  Thu Nov  2 11:02:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 11:02:27 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v13]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <vlCFCatlp5JzPipJxDbPtpNFrPEUL0ySxBi8uxNQPtc=.b66c78cd-035a-452a-baf5-6853cea3d9f4@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:

 - Merge branch 'master' into patch-10
 - Use permissive- to check for errors now in flags-cflags.m4
 - Formatting part two awt_Frame.cpp
 - Formatting awt_Frame.cpp
 - Split in awt_Frame.cpp
 - Formatting in awt_Component.cpp
 - Part two awt_Component.cpp
 - Split into declaration and assignment part one awt_Component.cpp
 - Formatting in awt_Canvas.cpp
 - Split declaration and assignment in awt_Canvas.cpp
 - ... and 32 more: https://git.openjdk.org/jdk/compare/64f8253b...0b2bda52

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

Changes: https://git.openjdk.org/jdk/pull/15096/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=12
  Stats: 508 lines in 12 files changed: 100 ins; 72 del; 336 mod
  Patch: https://git.openjdk.org/jdk/pull/15096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096

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

From jwaters at openjdk.org  Thu Nov  2 11:02:29 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 11:02:29 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v12]
In-Reply-To: <LkawUol8ApqyZ9AVsj6MPLMRTbufSaCRFH3s6mxp9ho=.7f64614d-758d-4139-a4d4-7b6d2875993e@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <LkawUol8ApqyZ9AVsj6MPLMRTbufSaCRFH3s6mxp9ho=.7f64614d-758d-4139-a4d4-7b6d2875993e@github.com>
Message-ID: <uBi-cIUzYgpy08j15Q4ADYWTpO1r_5ueX6jid_KN5sI=.b186498c-4843-4cf6-b9e0-459b6f13923a@github.com>

On Thu, 2 Nov 2023 10:52:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Formatting part two awt_Frame.cpp
>  - Formatting awt_Frame.cpp
>  - Split in awt_Frame.cpp

I am only adding permissive- to check for any flaws I have left in there, rest assured I will not be integrating the permissive- flag in this changeset

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1790503558

From jwaters at openjdk.org  Thu Nov  2 11:07:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 2 Nov 2023 11:07:27 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Changes awt_Frame.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/0b2bda52..81a3ffef

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

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

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

From stuefe at openjdk.org  Thu Nov  2 11:10:14 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 2 Nov 2023 11:10:14 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v13]
In-Reply-To: <vlCFCatlp5JzPipJxDbPtpNFrPEUL0ySxBi8uxNQPtc=.b66c78cd-035a-452a-baf5-6853cea3d9f4@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <vlCFCatlp5JzPipJxDbPtpNFrPEUL0ySxBi8uxNQPtc=.b66c78cd-035a-452a-baf5-6853cea3d9f4@github.com>
Message-ID: <bBTJrMI4WuuSg9j1_8hMNCuOcMOwQQFHyp_XLmMCvJ4=.00da5458-1c2e-4955-b3cc-0fd531ad3ef4@github.com>

On Thu, 2 Nov 2023 11:02:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits:
> 
>  - Merge branch 'master' into patch-10
>  - Use permissive- to check for errors now in flags-cflags.m4
>  - Formatting part two awt_Frame.cpp
>  - Formatting awt_Frame.cpp
>  - Split in awt_Frame.cpp
>  - Formatting in awt_Component.cpp
>  - Part two awt_Component.cpp
>  - Split into declaration and assignment part one awt_Component.cpp
>  - Formatting in awt_Canvas.cpp
>  - Split declaration and assignment in awt_Canvas.cpp
>  - ... and 32 more: https://git.openjdk.org/jdk/compare/64f8253b...0b2bda52

I'm removing myself from this. There are enough eyes on this.

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1790521227

From mbaesken at openjdk.org  Thu Nov  2 12:44:28 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Nov 2023 12:44:28 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v3]
In-Reply-To: <TV9mDcECvmcX1Rr14VOSOC4xAA4qBZWVZDZWHRXISvE=.bbb1e620-446f-4362-9284-9afee9dfc107@github.com>
References: <TV9mDcECvmcX1Rr14VOSOC4xAA4qBZWVZDZWHRXISvE=.bbb1e620-446f-4362-9284-9afee9dfc107@github.com>
Message-ID: <BBnESqT_-0xu8ZOxSKqB0B2Ku0JP3CMkAvglzGdfLIk=.3a390a0e-feb5-4b7d-bd2e-70ee15689750@github.com>

> There is an early return in Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c that seems to miss a ReleaseIntArrayElements call.

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

  remove JNU_ThrowOutOfMemoryError

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16392/files
  - new: https://git.openjdk.org/jdk/pull/16392/files/6dbed1aa..a51a7e16

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

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

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

From mbaesken at openjdk.org  Thu Nov  2 12:44:31 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 2 Nov 2023 12:44:31 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: <CsbycGLw7ghINgjPgn3hDt7N_ClDSX-yd8xgZ6NX6_w=.87c8c714-0d13-4582-bfec-84a1d883376c@github.com>
References: <TV9mDcECvmcX1Rr14VOSOC4xAA4qBZWVZDZWHRXISvE=.bbb1e620-446f-4362-9284-9afee9dfc107@github.com>
 <CsbycGLw7ghINgjPgn3hDt7N_ClDSX-yd8xgZ6NX6_w=.87c8c714-0d13-4582-bfec-84a1d883376c@github.com>
Message-ID: <2HkdRnTt0g9OpjQrlvkqtP6IzJFJLGeWn1WDz-ab3XE=.0dc2cedb-5bec-43d9-8fa5-31397eaa1d4e@github.com>

On Mon, 30 Oct 2023 09:15:00 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is an early return in Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c that seems to miss a ReleaseIntArrayElements call.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add JNU_ThrowOutOfMemoryError

Hi Phil, I removed the previously added JNU_ThrowOutOfMemoryError  .

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

PR Comment: https://git.openjdk.org/jdk/pull/16392#issuecomment-1790654845

From erikj at openjdk.org  Thu Nov  2 13:28:04 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 2 Nov 2023 13:28:04 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
Message-ID: <tLJ50-xAmV2FYb28kOQOLXgykhr_p4NHu4qVaQaXdjc=.6d2930db-b6b5-4c9e-af2d-d82870b05d23@github.com>

On Thu, 2 Nov 2023 07:14:14 GMT, null <duke at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> null has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 508:

> 506:    # expansion-to-defined required for GCC 9 builds. Not required for GCC 10+.
> 507:    # maybe-uninitialized required for GCC 8 builds. Not required for GCC 9+.
> 508:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type expansion-to-defined dangling-reference maybe-uninitialized

This line is getting very long, could you break it up?
Suggestion:

   HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type \
       expansion-to-defined dangling-reference maybe-uninitialized

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16468#discussion_r1380095140

From duke at openjdk.org  Thu Nov  2 14:01:23 2023
From: duke at openjdk.org (null)
Date: Thu, 2 Nov 2023 14:01:23 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
Message-ID: <8Kpx6CBAu3YKxosI4vybK1YmTWIRAav6JdRNSLnt9V4=.2ef36793-5efb-4c56-b4a9-c599f0f45f7f@github.com>

On Thu, 2 Nov 2023 07:14:14 GMT, null <duke at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> null has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add comments

@erikj79 
Thanks for the review.
The code has been updated

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1790790052

From duke at openjdk.org  Thu Nov  2 14:01:20 2023
From: duke at openjdk.org (null)
Date: Thu, 2 Nov 2023 14:01:20 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v3]
In-Reply-To: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
Message-ID: <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>

> Build failure with GCC8.3.1
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->ascender = max;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->descender = min;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> At global scope:
> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
> cc1plus: all warnings being treated as errors
> 
> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
> === End of repeated output ===
> 
> No indication of failed target found.
> HELP: Try searching the build log for '] Error'.
> HELP: Run 'make doctor' to diagnose build problems.
> 
> make[1]: *** [main] Error 1
> make: *** [images] Error 2

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

  Update make/modules/java.desktop/lib/Awt2dLibraries.gmk
  
  break  up line
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16468/files
  - new: https://git.openjdk.org/jdk/pull/16468/files/c4f20e30..95c4de2a

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

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

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

From erikj at openjdk.org  Thu Nov  2 15:01:05 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 2 Nov 2023 15:01:05 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v3]
In-Reply-To: <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
Message-ID: <-blEn92BW5lzSTUimsi8sLjT67O0BvZpCZSZ2pfjjBs=.bac28a1e-a759-489b-b351-7b594d61af74@github.com>

On Thu, 2 Nov 2023 14:01:20 GMT, null <duke at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> null has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/modules/java.desktop/lib/Awt2dLibraries.gmk
>   
>   break  up line
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16468#pullrequestreview-1710518852

From abhiscxk at openjdk.org  Thu Nov  2 16:02:27 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 2 Nov 2023 16:02:27 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
Message-ID: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>

JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.

CI jobs are green after the fix. Links attached to JBS.

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

Commit messages:
 - ProgressBar border paint fix

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

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

From zsong at openjdk.org  Thu Nov  2 16:12:08 2023
From: zsong at openjdk.org (Zhao Song)
Date: Thu, 2 Nov 2023 16:12:08 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <8Kpx6CBAu3YKxosI4vybK1YmTWIRAav6JdRNSLnt9V4=.2ef36793-5efb-4c56-b4a9-c599f0f45f7f@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
 <8Kpx6CBAu3YKxosI4vybK1YmTWIRAav6JdRNSLnt9V4=.2ef36793-5efb-4c56-b4a9-c599f0f45f7f@github.com>
Message-ID: <wc7a2Nnyiwx04xOKNKqsREr5zWS65dPBr6d0DLUiyl8=.45e462d0-1d85-4649-88ea-a20a430af986@github.com>

On Thu, 2 Nov 2023 13:58:01 GMT, null <duke at openjdk.org> wrote:

>> null has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add comments
>
> @erikj79 
> Thanks for the review.
> The code has been updated

Hi @xpbob, 
The jcheck is continuously failing because your GitHub name is `null`. Please set your name in your profile.
And out of curiosity, I want to know did you set your name to "xpbob" previously and recently removed it?
Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1791034302

From prr at openjdk.org  Thu Nov  2 17:54:07 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Nov 2023 17:54:07 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v3]
In-Reply-To: <BBnESqT_-0xu8ZOxSKqB0B2Ku0JP3CMkAvglzGdfLIk=.3a390a0e-feb5-4b7d-bd2e-70ee15689750@github.com>
References: <TV9mDcECvmcX1Rr14VOSOC4xAA4qBZWVZDZWHRXISvE=.bbb1e620-446f-4362-9284-9afee9dfc107@github.com>
 <BBnESqT_-0xu8ZOxSKqB0B2Ku0JP3CMkAvglzGdfLIk=.3a390a0e-feb5-4b7d-bd2e-70ee15689750@github.com>
Message-ID: <B5qUVAC3K3tJLvmoIFO06lw4AxcWQsgxejAA2aOWhtg=.b1345e38-5e8a-4eed-a8f5-f9f3e703742c@github.com>

On Thu, 2 Nov 2023 12:44:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is an early return in Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c that seems to miss a ReleaseIntArrayElements call.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove JNU_ThrowOutOfMemoryError

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16392#pullrequestreview-1710943919

From prr at openjdk.org  Thu Nov  2 17:54:08 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Nov 2023 17:54:08 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v3]
In-Reply-To: <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
Message-ID: <9QSJO5XxG8zqQAMfODdBFjOaFh6VL6NyixPfxSQCF4Q=.5248e187-c36f-4f87-9a6a-db4ef92ddee8@github.com>

On Thu, 2 Nov 2023 14:01:20 GMT, null <duke at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> null has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/modules/java.desktop/lib/Awt2dLibraries.gmk
>   
>   break  up line
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

looks ok

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16468#pullrequestreview-1710943036

From aivanov at openjdk.org  Thu Nov  2 18:19:18 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 2 Nov 2023 18:19:18 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v8]
In-Reply-To: <71Kog6sDk_17WiI_9AU1y1zKnFW53V6nupE-bUFbMl8=.c259ed45-06cf-4c9d-8242-0a9fe9a8e333@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <71Kog6sDk_17WiI_9AU1y1zKnFW53V6nupE-bUFbMl8=.c259ed45-06cf-4c9d-8242-0a9fe9a8e333@github.com>
Message-ID: <v3cC-Xir-wco0UHI_vkkxrrbEIRZwkoCGyiSBsXTpwE=.534088a8-7c80-444f-9c38-a9a199fa1eaa@github.com>

On Tue, 26 Sep 2023 11:12:08 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
>> 
>> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
>> 
>> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - AccessibleName set in Listener
>  - Master
>  - Revert BasicComboBoxUI fix and update review comment
>  - bugid removed in comments
>  - Add condition to check JLabel instance
>  - set accessiblename to displayed text in JComboBox
>  - Merge
>  - Explicit frame dispose remove
>  - merge
>  - Review comment update
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/4b9a198e...1a48076b

This is definitely an improvement compared to the complete lack of magnified text on hover, but it still doesn't handle custom renderers.

I've been digging into how this works in Metal but I couldn't figure it out completely. Eventually, it gets to `JList` of the popup, the list returns the renderer component as its child at the specified position ? this is how text from the renderer gets used as the accessible name.

This should work for Aqua L&F too, all UI classes are derived from `BasicUI`, but for whatever reason it doesn't, and I didn't figure it out unfortunately.

However, I came up with an alternative solution which handles custom renderers nicely. You can find my version at [commit eee17ca](https://github.com/openjdk/jdk/commit/eee17ca7fc07fb87997040589bde83f5fad9fdea), it shows the changes to your latest version in the PR. You can also view [the diff to jdk/master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:eee17ca7fc07fb87997040589bde83f5fad9fdea).

Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. I spent quite a lot of time, and it requires even more time to understand how it gets to `JList.AccessibleJList` and `AccessibleJListChild`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1791291765

From achung at openjdk.org  Thu Nov  2 19:08:12 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 2 Nov 2023 19:08:12 GMT
Subject: Integrated: 8316028: Update FreeType to 2.13.2
In-Reply-To: <RQQ6lzVIhKuGStz0kHQzuxmj9ShxPQTGgX641XZ1ykI=.21e5d445-415f-4c51-8fc8-4cd116572c70@github.com>
References: <RQQ6lzVIhKuGStz0kHQzuxmj9ShxPQTGgX641XZ1ykI=.21e5d445-415f-4c51-8fc8-4cd116572c70@github.com>
Message-ID: <iPvxJs1mNJ9YCJHKEqQyNSSi6UiNnsZ6G35phFYPPV4=.66bb15c9-d834-4c16-8221-50cbc191f1aa@github.com>

On Thu, 26 Oct 2023 21:45:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updating freetype
> mach5 build is green

This pull request has now been integrated.

Changeset: 3b65b879
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3b65b8797a0798474947d38d3facd17b3e89c602
Stats:     5484 lines in 100 files changed: 1565 ins; 2060 del; 1859 mod

8316028: Update FreeType to 2.13.2

Reviewed-by: serb, dnguyen

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

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

From dlong at openjdk.org  Thu Nov  2 19:18:13 2023
From: dlong at openjdk.org (Dean Long)
Date: Thu, 2 Nov 2023 19:18:13 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
Message-ID: <FCJmDVitEEQXQETg4b-LQifuE0h4Wa_0rEWhCd_IsHk=.766f9b1e-edbf-4ab8-95aa-21ab8fd24b05@github.com>

On Thu, 2 Nov 2023 11:07:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes awt_Frame.cpp

src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 220:

> 218:     c = (AwtCanvas*) pData;
> 219:     c->m_eraseBackground = doErase;
> 220:     c->m_eraseBackgroundOnResize = doEraseOnResize;

Suggestion:

    {
        AwtCanvas *c = (AwtCanvas*) pData;
        c->m_eraseBackground = doErase;
        c->m_eraseBackgroundOnResize = doEraseOnResize;
    }

Does wrapping in {} work?  I think it looks better, and that's how we handle case labels in switch statements, isn't it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1380668853

From prr at openjdk.org  Thu Nov  2 21:17:16 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Nov 2023 21:17:16 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
Message-ID: <GrblBP1ZbYiw3ZODAAler6XywHqN7_cdAM73QhlRFq8=.19dc1ad9-262f-4080-9874-fdcac9265a2b@github.com>

On Thu, 2 Nov 2023 11:07:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changes awt_Frame.cpp

src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 218:

> 216: 
> 217:     AwtCanvas *c;
> 218:     c = (AwtCanvas*) pData;

you probably explained it in some other thread, perhaps in an earlier review but what exactly is the problem with the existing code ? The new code looks like something that begs to be undone.

src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 61:

> 59: 
> 60: jfieldID AwtPrintDialog::pageID;
> 61: 

where and why did this come from ?

src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 533:

> 531: 
> 532:     {
> 533:         HWND parentID = AwtPrintControl::getParentID(env, self);

diff is making this really hard to compare line by line
So here you've just put the code in { .. } and indented ? 
What is the warning that motivates this ?
I don't see where you describe it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1380641669
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1380780091
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1380781297

From prr at openjdk.org  Thu Nov  2 21:17:18 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Nov 2023 21:17:18 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v2]
In-Reply-To: <cSTJYF5su4k6hSBrzsU8-6ZLWXxMM32ejittl1WQr7s=.413310fb-233a-4b94-804a-9a7bf2892a54@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <Qe5ihlyAofq8xiGUpBxmzNMwWzSxt7IkDq3rIteHXQA=.6742f48e-520e-476f-86c6-78d92b506ed0@github.com>
 <uCQ7DIHikf7YjzvLIXdgSWUt0nSC878IILDqbJiwGd4=.da36070f-65b4-4dd6-b287-c793ae67841d@github.com>
 <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com>
 <s_ecVF-C_gg4LoToWOdVxXbQtwhlx1tLONpYY_PaJLA=.847514bd-d595-4e52-b33b-f427b4613c6b@github.com>
 <cSTJYF5su4k6hSBrzsU8-6ZLWXxMM32ejittl1WQr7s=.413310fb-233a-4b94-804a-9a7bf2892a54@github.com>
Message-ID: <0F1TFKzW-_Rehse3Ky9er9QvLEo5iaWZDjeYmr1Xk_0=.f3fe217d-7adb-4523-8893-1f4db625457e@github.com>

On Fri, 11 Aug 2023 07:41:45 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Oh. That's not good. Having such an undocumented reliance on order of include just begs to bitrot at some point. Any chance you could unravel that mystery, maybe in a later RFE? For now, can you please add a comment at those places where you changed include order for that reason?
>
> I can try doing that, yes. There was actually a commit before this one that addressed the same issue in awt, but it missed this one since without -permissive- this error isn't caught, see [8241087](https://bugs.openjdk.org/browse/JDK-8241087)
> 
> Looking at the error logs, I believe this may be due to an issue this causes with templates in the comip.h header, but I don't think that's the main problem to be worried about, rather it's that malloc (and calloc and realloc and the JDK's ExceptionOccured method too by the way) is redefined like this in the first place. I don't have any ideas for how to deal with that at the moment unfortunately

this is very worrying as it seems to suggest that in the same C++ source file we have  some code that wants the standard malloc, some that wants a redefined malloc, and 
I've no idea of the consequences.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1380640040

From prr at openjdk.org  Thu Nov  2 21:17:20 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Nov 2023 21:17:20 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <vkCIt2_m0R1DLkcOEWuKxoWYFT8mpzwJeL-9pl_SGMg=.5de2c231-b5a1-4dd3-b605-8f5077041bfe@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <Qe5ihlyAofq8xiGUpBxmzNMwWzSxt7IkDq3rIteHXQA=.6742f48e-520e-476f-86c6-78d92b506ed0@github.com>
 <uCQ7DIHikf7YjzvLIXdgSWUt0nSC878IILDqbJiwGd4=.da36070f-65b4-4dd6-b287-c793ae67841d@github.com>
 <vkCIt2_m0R1DLkcOEWuKxoWYFT8mpzwJeL-9pl_SGMg=.5de2c231-b5a1-4dd3-b605-8f5077041bfe@github.com>
Message-ID: <UQZ6Ik0jNQmMSKJHFx7uBvBXDlkh31_DxJNrJ7eipho=.4ee2dc07-da73-4a2e-9ca0-1002ee807cd8@github.com>

On Thu, 21 Sep 2023 09:17:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_DnDDT.cpp line 34:
>> 
>>> 32: #include "sun_awt_windows_WDropTargetContextPeer.h"
>>> 33: #include "awt_Container.h"
>>> 34: #include "awt_ole.h"
>> 
>> Why?
>
> Is this related to the `#define malloc Do_Not_Use_Malloc` issue? If so, the required ordering of includes should be documented here as well.

agreed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1380636643

From prr at openjdk.org  Thu Nov  2 21:54:01 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Nov 2023 21:54:01 GMT
Subject: RFR: 8318023: Implement IPP output-bin attribute extension on
 macOS [v2]
In-Reply-To: <i6w3g-lVIQOdiDFJTMRNAR9IPyiaNRatpOI0PXzDjRM=.bf59b6e8-b9aa-49f6-bda8-4ed9edf41580@github.com>
References: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
 <mdJEiLAM6PHI4u14iy9VdzzRDCQw_PVKV5hWUV4TZbU=.36e9799a-5f51-43b4-9b21-230177cfd3dd@github.com>
 <KL8trj94_xH7KM58xU5QIAgmaq-LbjtxBQP69A7iA-Y=.a1831a38-984a-4c7b-bb51-ab5eafd4a01f@github.com>
 <i6w3g-lVIQOdiDFJTMRNAR9IPyiaNRatpOI0PXzDjRM=.bf59b6e8-b9aa-49f6-bda8-4ed9edf41580@github.com>
Message-ID: <73n3w1ZcwYIy2PlYR5st5nQ0G85XJvuAlLRxTKTwHdQ=.9a5f9d76-73f4-4016-b420-92055f0b9013@github.com>

On Wed, 18 Oct 2023 17:14:06 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> > Why did you file a new RFE when you know about the existing one ? Close your new one as a dup. and redirect everything to the existing one. Also I don't see any UI work to enhance the dialog so it can be selected. And why restrict it to macOS ? Is it an issue of testing ?
> 
> My idea was to use JDK-8314070 as an umbrella and provide fixes for macOS, Linux, and Windows separately. While the OutputBin public API is not fixed any change in it would require to re-test the fix on all 3 platforms. The fix for the UI dialog requires an additional test with a printer dialog so there would be 2 tests for each platform for re-testing for each essential change in the fix.

I'm struggling to follow the logic.
This change clearly contains the public API which is the first thing you need.
Burying it in the fix for one platform that happens to be the first one you coded isn't right.

If you really want to stagger it then proceed as follows
1) Add just the new API class under the existing RFE
2) Add  this macOS support for it under this ID
3) Add the Swing dialog UI support for selecting the bin - easier once you have one implementation
4) Add Linux support (CUPS, so should be similar to macOS)
5) Add Windows support, but SFAIK GDI has no support for this, so likely impossible to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/16166#issuecomment-1791587457

From duke at openjdk.org  Thu Nov  2 23:25:31 2023
From: duke at openjdk.org (ScientificWare)
Date: Thu, 2 Nov 2023 23:25:31 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v3]
In-Reply-To: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
Message-ID: <CPIiUNpDS0fTvULhPl_ibsJlkONTXevFQYIEq5-e8yU=.8aec4739-e1c8-460d-8300-482cd298c352@github.com>

> This is referenced in Java Bug Database as
> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731)
> 
> This is tracked in JBS as
> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731)
> 
> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input)
> 
> `alt` is not an attribute of the `input` element.
> 
> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : 
> 
>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ...
> 
> This feature is not implemented in `FormView.java`.
> 
> ??  ~~This also affects the HTML 32 DTD~~
> 
> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138)
> 
> Left before the patch and right after the patch.
> 
> 
> import java.awt.BorderLayout;
> import java.awt.Dimension;
> import javax.swing.JEditorPane;
> import javax.swing.JFrame;
> import javax.swing.JScrollPane;
> import javax.swing.SwingUtilities;
> import javax.swing.text.Document;
> import javax.swing.text.html.HTMLEditorKit;
> import javax.swing.text.html.StyleSheet;
> 
> public class HTMLAddsSupportAltInputTag {
>   public static void main(String[] args) {
>     new HTMLAddsSupportAltInputTag();
>   }
>   
>   public HTMLAddsSupportAltInputTag() {
>     SwingUtilities.invokeLater(new Runnable(){
>       public void run(){
>         JEditorPane jEditorPane = new JEditorPane();
>         jEditorPane.setEditable(false);
>         JScrollPane scrollPane = new JScrollPane(jEditorPane);
>         HTMLEditorKit kit = new HTMLEditorKit();
>         jEditorPane.setEditorKit(kit);
>         StyleSheet styleSheet = kit.getStyleSheet();
>         styleSheet.addRule("""
>             body {
>                 color: #000;
>                 font-family:times;
>                 margin: 4px;
>             }
>             """);
>         String htmlString = """
>             <html>
>                 <body>
>                     <input type=image name=point src="file:oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>                     <p>
>                     <input type=image name=point src="file:none_oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>                     <p>
>                     <input type=image name=point src...

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

 - Merge master
 - FormView.java :
   - Pass altAtt as the description parameter in the ImageIcon constructor.
 - Merge branch 'scientificware-patch-006-HTML-adds_input_tag_image_type_alt_attribute_support' of github.com:scientificware/jdk into scientificware-patch-006-HTML-adds_input_tag_image_type_alt_attribute_support
 - Update src/java.desktop/share/classes/javax/swing/text/html/FormView.java
   
   FormView.java : Remove a redundant space.
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Merge master
 - Merge master
 - Merge master
 - FormView.java :
   - Fall back to the src attribute if the alt attribute is missing.
 - FormView.java : Adds missing space in a while statement. Updates Copyright year.
 - Merge master
 - ... and 1 more: https://git.openjdk.org/jdk/compare/98c1c6dd...a3e8ce51

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15319/files
  - new: https://git.openjdk.org/jdk/pull/15319/files/0e08107b..a3e8ce51

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

  Stats: 219933 lines in 5760 files changed: 111084 ins; 48750 del; 60099 mod
  Patch: https://git.openjdk.org/jdk/pull/15319.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15319/head:pull/15319

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

From duke at openjdk.org  Fri Nov  3 00:27:11 2023
From: duke at openjdk.org (Alec Su)
Date: Fri, 3 Nov 2023 00:27:11 GMT
Subject: RFR: 8319315: Sending a SysexMessage starting with 0xF7 leads to JVM
 crash
Message-ID: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>

The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.

On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.

The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.

https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144

To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.

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

Commit messages:
 - Fix crashes when sending a SysexMessage starting with 0xF7

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

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

From jwaters at openjdk.org  Fri Nov  3 02:36:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 02:36:12 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <GrblBP1ZbYiw3ZODAAler6XywHqN7_cdAM73QhlRFq8=.19dc1ad9-262f-4080-9874-fdcac9265a2b@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
 <GrblBP1ZbYiw3ZODAAler6XywHqN7_cdAM73QhlRFq8=.19dc1ad9-262f-4080-9874-fdcac9265a2b@github.com>
Message-ID: <7NYI5rSaTjvVJyxcBDQCKBUgQUIupdBBFVyn5krNwjI=.215b8659-bd54-4743-abce-dd1f82ba7974@github.com>

On Thu, 2 Nov 2023 18:47:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes awt_Frame.cpp
>
> src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 218:
> 
>> 216: 
>> 217:     AwtCanvas *c;
>> 218:     c = (AwtCanvas*) pData;
> 
> you probably explained it in some other thread, perhaps in an earlier review but what exactly is the problem with the existing code ? The new code looks like something that begs to be undone.

The problem is that the goto jumps over the initialization of these locals, which C++ does not allow. However, a split declaration and assignment can be jumped over by goto if the local is a primitive type, hence this change is needed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1381109525

From jwaters at openjdk.org  Fri Nov  3 02:36:15 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 02:36:15 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <FCJmDVitEEQXQETg4b-LQifuE0h4Wa_0rEWhCd_IsHk=.766f9b1e-edbf-4ab8-95aa-21ab8fd24b05@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
 <FCJmDVitEEQXQETg4b-LQifuE0h4Wa_0rEWhCd_IsHk=.766f9b1e-edbf-4ab8-95aa-21ab8fd24b05@github.com>
Message-ID: <pyq_HDI8qfsCEfTPjuAAt9A4slGBF5S-dOdPIIxt_cg=.5fcc9a56-df03-499e-a03a-42528f4f561f@github.com>

On Thu, 2 Nov 2023 19:15:42 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes awt_Frame.cpp
>
> src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 220:
> 
>> 218:     c = (AwtCanvas*) pData;
>> 219:     c->m_eraseBackground = doErase;
>> 220:     c->m_eraseBackgroundOnResize = doEraseOnResize;
> 
> Suggestion:
> 
>     {
>         AwtCanvas *c = (AwtCanvas*) pData;
>         c->m_eraseBackground = doErase;
>         c->m_eraseBackgroundOnResize = doEraseOnResize;
>     }
> 
> Does wrapping in {} work?  I think it looks better, and that's how we handle case labels in switch statements, isn't it?

Wrapping it in a scope does work, but the problem is that it unfortunately becomes very messy and hard to review when the scope spans over a lot of lines (see below for instance, where I haven't switched from a scope to the split declaration and assignment yet). This approach was suggested by @djelinski in the review of https://github.com/openjdk/jdk/pull/15996

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1381110740

From jwaters at openjdk.org  Fri Nov  3 02:43:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 02:43:11 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v2]
In-Reply-To: <0F1TFKzW-_Rehse3Ky9er9QvLEo5iaWZDjeYmr1Xk_0=.f3fe217d-7adb-4523-8893-1f4db625457e@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <Qe5ihlyAofq8xiGUpBxmzNMwWzSxt7IkDq3rIteHXQA=.6742f48e-520e-476f-86c6-78d92b506ed0@github.com>
 <uCQ7DIHikf7YjzvLIXdgSWUt0nSC878IILDqbJiwGd4=.da36070f-65b4-4dd6-b287-c793ae67841d@github.com>
 <4h94NwPm9PLMkf0Dmc4Iqlg6tT-A_SUNXYeL0mxJ5eQ=.bc51f855-a69d-4f5b-b657-277a57f45ba3@github.com>
 <s_ecVF-C_gg4LoToWOdVxXbQtwhlx1tLONpYY_PaJLA=.847514bd-d595-4e52-b33b-f427b4613c6b@github.com>
 <cSTJYF5su4k6hSBrzsU8-6ZLWXxMM32ejittl1WQr7s=.413310fb-233a-4b94-804a-9a7bf2892a54@github.com>
 <0F1TFKzW-_Rehse3Ky9er9QvLEo5iaWZDjeYmr1Xk_0=.f3fe217d-7adb-4523-8893-1f4db625457e@github.com>
Message-ID: <BhXbz6s_noKSNXozUxaDobtUtebs67dIxbD1mItQfBI=.4b88803e-541a-4b7f-9b3f-2662c3a9e7a1@github.com>

On Thu, 2 Nov 2023 18:46:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> I can try doing that, yes. There was actually a commit before this one that addressed the same issue in awt, but it missed this one since without -permissive- this error isn't caught, see [8241087](https://bugs.openjdk.org/browse/JDK-8241087)
>> 
>> Looking at the error logs, I believe this may be due to an issue this causes with templates in the comip.h header, but I don't think that's the main problem to be worried about, rather it's that malloc (and calloc and realloc and the JDK's ExceptionOccured method too by the way) is redefined like this in the first place. I don't have any ideas for how to deal with that at the moment unfortunately
>
> this is very worrying as it seems to suggest that in the same C++ source file we have  some code that wants the standard malloc, some that wants a redefined malloc, and 
> I've no idea of the consequences.

To my knowledge this has been an issue before, and was fixed by [8241087](https://bugs.openjdk.org/browse/JDK-8241087), but it missed this one. The code that needs the malloc is in a template in Microsoft's headers, which I don't think we can change. I'm not sure what other solution we can come up with for this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1381111882

From jwaters at openjdk.org  Fri Nov  3 02:43:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 02:43:12 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <UQZ6Ik0jNQmMSKJHFx7uBvBXDlkh31_DxJNrJ7eipho=.4ee2dc07-da73-4a2e-9ca0-1002ee807cd8@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <Qe5ihlyAofq8xiGUpBxmzNMwWzSxt7IkDq3rIteHXQA=.6742f48e-520e-476f-86c6-78d92b506ed0@github.com>
 <uCQ7DIHikf7YjzvLIXdgSWUt0nSC878IILDqbJiwGd4=.da36070f-65b4-4dd6-b287-c793ae67841d@github.com>
 <vkCIt2_m0R1DLkcOEWuKxoWYFT8mpzwJeL-9pl_SGMg=.5de2c231-b5a1-4dd3-b605-8f5077041bfe@github.com>
 <UQZ6Ik0jNQmMSKJHFx7uBvBXDlkh31_DxJNrJ7eipho=.4ee2dc07-da73-4a2e-9ca0-1002ee807cd8@github.com>
Message-ID: <2D5YVYYwwpS_lwpTelvseXTF7UYQMKgLI1waR64aU74=.00ba4b12-b578-47b2-87e7-efc66a5401bf@github.com>

On Thu, 2 Nov 2023 18:43:14 GMT, Phil Race <prr at openjdk.org> wrote:

>> Is this related to the `#define malloc Do_Not_Use_Malloc` issue? If so, the required ordering of includes should be documented here as well.
>
> agreed

Will do

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1381111966

From jwaters at openjdk.org  Fri Nov  3 02:43:16 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 02:43:16 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <GrblBP1ZbYiw3ZODAAler6XywHqN7_cdAM73QhlRFq8=.19dc1ad9-262f-4080-9874-fdcac9265a2b@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
 <GrblBP1ZbYiw3ZODAAler6XywHqN7_cdAM73QhlRFq8=.19dc1ad9-262f-4080-9874-fdcac9265a2b@github.com>
Message-ID: <cke6teC1E1HwnOHkxcNMpN17Q3UpD2GJ5hmy7QAtnUc=.1b681083-648c-4cda-b174-90f38baf5cc3@github.com>

On Thu, 2 Nov 2023 21:10:45 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changes awt_Frame.cpp
>
> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 61:
> 
>> 59: 
>> 60: jfieldID AwtPrintDialog::pageID;
>> 61: 
> 
> where and why did this come from ?

This came from below, all I did was move it up and out of the extern "C" block. This cannot be inside extern "C" because it is a static class member and has permanent C++ name mangling

> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 533:
> 
>> 531: 
>> 532:     {
>> 533:         HWND parentID = AwtPrintControl::getParentID(env, self);
> 
> diff is making this really hard to compare line by line
> So here you've just put the code in { .. } and indented ? 
> What is the warning that motivates this ?
> I don't see where you describe it.

I haven't gotten around to converting this to the new approach of splitting declaration and assignment, but yes, that is all I've done. I've described the problem here above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1381112565
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1381113001

From jwaters at openjdk.org  Fri Nov  3 03:05:37 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 03:05:37 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v15]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <xOyb-nTjbHYCmR5-cTaOw3wH8uMJLZxF7gUV8tET0_Q=.7be50c32-6cc1-4cdd-b4b7-a190624888cf@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Part one awt_PrintJob.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/81a3ffef..eea56c65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=13-14

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

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

From duke at openjdk.org  Fri Nov  3 03:06:11 2023
From: duke at openjdk.org (xpbob)
Date: Fri, 3 Nov 2023 03:06:11 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v3]
In-Reply-To: <9QSJO5XxG8zqQAMfODdBFjOaFh6VL6NyixPfxSQCF4Q=.5248e187-c36f-4f87-9a6a-db4ef92ddee8@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
 <9QSJO5XxG8zqQAMfODdBFjOaFh6VL6NyixPfxSQCF4Q=.5248e187-c36f-4f87-9a6a-db4ef92ddee8@github.com>
Message-ID: <ev464F4phx6WDB0A-Gr8CNu9sQ4QooJq4FPHVP44F5I=.6bf9784a-f2e3-4367-9a89-7b9202edf1aa@github.com>

On Thu, 2 Nov 2023 17:51:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update make/modules/java.desktop/lib/Awt2dLibraries.gmk
>>   
>>   break  up line
>>   
>>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
>
> looks ok

@prrace 
Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1791839520

From duke at openjdk.org  Fri Nov  3 03:13:07 2023
From: duke at openjdk.org (xpbob)
Date: Fri, 3 Nov 2023 03:13:07 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v3]
In-Reply-To: <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
Message-ID: <X_4se-cWV1zCcy4tYA-6nF2Fj1bJqgyCLXOW3dZoNkY=.3ee7a1e8-7e6f-4cb2-816c-87f7d9cfbddc@github.com>

On Thu, 2 Nov 2023 14:01:20 GMT, xpbob <duke at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/modules/java.desktop/lib/Awt2dLibraries.gmk
>   
>   break  up line
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Pipeline test case java\lang\ClassLoader\loadLibraryDeadlock\LoadLibraryDeadlock.java failed In the windows-x64 / test - Test (tier1) environment
The code changes do not involve this module.

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1791842575

From duke at openjdk.org  Fri Nov  3 03:23:01 2023
From: duke at openjdk.org (xpbob)
Date: Fri, 3 Nov 2023 03:23:01 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <wc7a2Nnyiwx04xOKNKqsREr5zWS65dPBr6d0DLUiyl8=.45e462d0-1d85-4649-88ea-a20a430af986@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
 <8Kpx6CBAu3YKxosI4vybK1YmTWIRAav6JdRNSLnt9V4=.2ef36793-5efb-4c56-b4a9-c599f0f45f7f@github.com>
 <wc7a2Nnyiwx04xOKNKqsREr5zWS65dPBr6d0DLUiyl8=.45e462d0-1d85-4649-88ea-a20a430af986@github.com>
Message-ID: <wS3vokQcXb_EEHLtuaFyVdS8ra2ZYi8Kp-SkOxJaH-Y=.4b92b96b-d2e3-4b85-aa1b-55e15d92e830@github.com>

On Thu, 2 Nov 2023 16:09:28 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> @erikj79 
>> Thanks for the review.
>> The code has been updated
>
> Hi @xpbob, 
> The jcheck is continuously failing because your GitHub name is `null`. Please set your name in your profile.
> And out of curiosity, I want to know did you set your name to "xpbob" previously and recently removed it?
> Thanks

@zhaosongzs 
Thank you for your suggestions
xpbob is my account name, and when I click on profile, the name is empty. I set it up and jcheck worked

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1791847332

From jwaters at openjdk.org  Fri Nov  3 03:42:29 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 03:42:29 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v16]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <yQr80gigHW4OrfB_nTBB1KgtPrDQ9m7h85E7K3PJESI=.0f542176-e358-45f4-9f60-dead9f31ba61@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Discard unneeded changes awt_Frame.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/eea56c65..ce018e16

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=14-15

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

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

From jwaters at openjdk.org  Fri Nov  3 03:50:45 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 03:50:45 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v17]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <N_u-iL_Kyphp2g1eZe-GEQQk0j5_dGEb-1MS5UgH3B4=.24da261b-5688-4ae8-bded-8c693c809e77@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Unneeded changes part two awt_Frame.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/ce018e16..f1fc258c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=15-16

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

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

From duke at openjdk.org  Fri Nov  3 03:52:11 2023
From: duke at openjdk.org (xpbob)
Date: Fri, 3 Nov 2023 03:52:11 GMT
Subject: Integrated: 8319268: Build failure with GCC8.3.1 after 8313643
In-Reply-To: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
Message-ID: <EdiGU4Rs-V7TEGfhJ1eI8b3_1l_khvgx5sUT6C3eQZI=.d97d9ff0-0898-477f-8b16-d17e4fca46b0@github.com>

On Thu, 2 Nov 2023 04:29:01 GMT, xpbob <duke at openjdk.org> wrote:

> Build failure with GCC8.3.1
> 
> === Output from failing command(s) repeated here ===
> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->ascender = max;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>        extents->descender = min;
>        ~~~~~~~~~~~~~~~~~~~^~~~~
> At global scope:
> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
> cc1plus: all warnings being treated as errors
> 
> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
> === End of repeated output ===
> 
> No indication of failed target found.
> HELP: Try searching the build log for '] Error'.
> HELP: Run 'make doctor' to diagnose build problems.
> 
> make[1]: *** [main] Error 1
> make: *** [images] Error 2

This pull request has now been integrated.

Changeset: ec79ab4b
Author:    xpbob <609083568 at qq.com>
Committer: Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec79ab4b3cd89c2c0a9c8550cd62433bd6d45266
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8319268: Build failure with GCC8.3.1 after 8313643

Reviewed-by: jiefu, erikj, prr

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

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

From zsong at openjdk.org  Fri Nov  3 04:07:10 2023
From: zsong at openjdk.org (Zhao Song)
Date: Fri, 3 Nov 2023 04:07:10 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <wc7a2Nnyiwx04xOKNKqsREr5zWS65dPBr6d0DLUiyl8=.45e462d0-1d85-4649-88ea-a20a430af986@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
 <8Kpx6CBAu3YKxosI4vybK1YmTWIRAav6JdRNSLnt9V4=.2ef36793-5efb-4c56-b4a9-c599f0f45f7f@github.com>
 <wc7a2Nnyiwx04xOKNKqsREr5zWS65dPBr6d0DLUiyl8=.45e462d0-1d85-4649-88ea-a20a430af986@github.com>
Message-ID: <xdoWyMQ_Gxll_vgtzyru9nFdWgyIx5z63PMwxzNZ-40=.0def34d6-33ea-4772-9708-8be3554c2ed1@github.com>

On Thu, 2 Nov 2023 16:09:28 GMT, Zhao Song <zsong at openjdk.org> wrote:

>> @erikj79 
>> Thanks for the review.
>> The code has been updated
>
> Hi @xpbob, 
> The jcheck is continuously failing because your GitHub name is `null`. Please set your name in your profile.
> And out of curiosity, I want to know did you set your name to "xpbob" previously and recently removed it?
> Thanks

> @zhaosongzs Thank you for your suggestions xpbob is my account name, and when I click on profile, the name is empty. I set it up and jcheck worked I have not set a profile since I applied for an account.

OK, but if you never set your name in your GitHub profile, the jcheck should also fail in your previous PRs. It's weird...

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1791868356

From jwaters at openjdk.org  Fri Nov  3 04:12:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 04:12:46 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Part II awt_PrintJob.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/f1fc258c..60dbef3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=16-17

  Stats: 151 lines in 1 file changed: 17 ins; 1 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/15096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096

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

From prr at openjdk.org  Fri Nov  3 04:32:12 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Nov 2023 04:32:12 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v14]
In-Reply-To: <7NYI5rSaTjvVJyxcBDQCKBUgQUIupdBBFVyn5krNwjI=.215b8659-bd54-4743-abce-dd1f82ba7974@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <l2vCyhWOxveU_kNuceiPN73nvNCM1DfhpGwINZqhnQQ=.90a8f41f-6790-4dfa-81f8-cff790ddd287@github.com>
 <GrblBP1ZbYiw3ZODAAler6XywHqN7_cdAM73QhlRFq8=.19dc1ad9-262f-4080-9874-fdcac9265a2b@github.com>
 <7NYI5rSaTjvVJyxcBDQCKBUgQUIupdBBFVyn5krNwjI=.215b8659-bd54-4743-abce-dd1f82ba7974@github.com>
Message-ID: <yaKmBCnze7w2bZetcwftdRqeDIQ0U-SmgdgRVmWN-W0=.848b1ea9-e2f9-435e-a45f-ed156c2ff7e4@github.com>

On Fri, 3 Nov 2023 02:29:58 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 218:
>> 
>>> 216: 
>>> 217:     AwtCanvas *c;
>>> 218:     c = (AwtCanvas*) pData;
>> 
>> you probably explained it in some other thread, perhaps in an earlier review but what exactly is the problem with the existing code ? The new code looks like something that begs to be undone.
>
> The problem is that the goto jumps over the initialization of these locals, which C++ does not allow. However, a split declaration and assignment can be jumped over by goto if the local is a primitive type, hence this change is needed

Really I hate this change. It is wrong.  Well I could go further than that. I have no idea why C++ thinks one is OK and the other is not. Please show the EXACT WARNING FROM THE COMPILER. (Actually why aren't you showing us what the problems are ? )  I don't know if I want to change C++ or something else. Actually C++ is a problem in itself, but that's a personal opinion. If goto is the specific problem and the only thing we can change then we should eliminate goto.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1381150116

From prr at openjdk.org  Fri Nov  3 04:35:13 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Nov 2023 04:35:13 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
Message-ID: <CUa-99QQm5tTJSrjwz1IJnzJQiRSgdJhhNDOo61UVRQ=.a007cf75-c25f-414e-808f-24842ede9f2d@github.com>

On Fri, 3 Nov 2023 04:12:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Part II awt_PrintJob.cpp

For everyone of these changes, I want to see what the compiler says if you don't make the change. Else I am flying half blind.

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1791882072

From jwaters at openjdk.org  Fri Nov  3 04:52:12 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 04:52:12 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
Message-ID: <kR4PdMEmxH2hGMrmqOQOSP1nvaiKkV71tbBahDgL7T8=.85e80205-15b0-4a89-8c6e-9b1a870aa2f1@github.com>

On Fri, 3 Nov 2023 04:12:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Part II awt_PrintJob.cpp

Right, I can simply remove the changes and let the permissive- in the GitHub Actions do the talking

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1791890320

From psadhukhan at openjdk.org  Fri Nov  3 04:58:24 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 3 Nov 2023 04:58:24 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v5]
In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
Message-ID: <JtSABlREhW0PsiyMdZKJXEtrk3TpE75obI05pPrALJQ=.f38e1408-0c46-4d96-b5be-a62156b22cfe@github.com>

> javadoc contract for JComponent.setMinimumSize(Dimension) states:
> 
> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
> 
> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
> 
> Fix is made to check if mnimumSize is set and if so, honour it..

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

  Remove unneeded methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15325/files
  - new: https://git.openjdk.org/jdk/pull/15325/files/09b8b827..6a9a1d5a

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

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

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

From jwaters at openjdk.org  Fri Nov  3 05:00:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 05:00:13 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
Message-ID: <UGmhb3qan1A0F8fjIZWSedcfUSnZOBXE_A4gzxrS1Eo=.61eb98ff-3736-4ab8-af63-813c49e5aaed@github.com>

On Fri, 3 Nov 2023 04:12:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Part II awt_PrintJob.cpp

Actually, I can do you one better, now that I think of it, so I don't have to explains potentially deeply nested and confusing error logs:


int main() {
    goto skip;
    int i = 0;
    skip:
    std::printf("Done\n");
}


C:\Users\vertig0\Downloads>cl.exe -nologo -std:c++14 -permissive- -Fo:goto.o goto.cpp

goto.cpp(5): error C2362: initialization of 'c' is skipped by 'goto skip'
goto.cpp(6): note: see declaration of 'skip'

You simply cannot jump over initialization of a local with a goto in C++, as shown by the Visual C compiler above, does this answer your question?

https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2362?view=msvc-170

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1791894173
PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1791894511

From prr at openjdk.org  Fri Nov  3 05:09:14 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Nov 2023 05:09:14 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <UGmhb3qan1A0F8fjIZWSedcfUSnZOBXE_A4gzxrS1Eo=.61eb98ff-3736-4ab8-af63-813c49e5aaed@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
 <UGmhb3qan1A0F8fjIZWSedcfUSnZOBXE_A4gzxrS1Eo=.61eb98ff-3736-4ab8-af63-813c49e5aaed@github.com>
Message-ID: <9I1UnM0ZCBsPQiiGZ-Upz7ZiqCiUHdNHOJK7KTKlwzM=.6a54c57a-ae9c-4205-a501-400a589fa652@github.com>

On Fri, 3 Nov 2023 04:57:26 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Actually, I can do you one better, now that I think of it, so I don't have to explains potentially deeply nested and confusing error logs:
> 
> ```
> int main() {
>     goto skip;
>     int i = 0;
>     skip:
>     std::printf("Done\n");
> }
> ```
> 
> C:\Users\vertig0\Downloads>cl.exe -nologo -std:c++14 -permissive- -Fo:goto.o goto.cpp
> 
> goto.cpp(5): error C2362: initialization of 'c' is skipped by 'goto skip' goto.cpp(6): note: see declaration of 'skip'
> 
> You simply cannot jump over initialization of a local with a goto in C++, as shown by the Visual C compiler above, does this answer your question?

It tells me 2 things
(1) C++ is awful, because the change you made to silence it is a no-op
(2) the changes you are making are really wrong, because C++ is telling us it does not like goto, and you aren't addresssing that

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1791898759

From djelinski at openjdk.org  Fri Nov  3 06:09:00 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 3 Nov 2023 06:09:00 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <k_L1TnwIOXAazmC4cPBGkYlYIutMqQj-vVesd-oUrA8=.3234cc6e-5097-4729-bc61-ae0d7c72872e@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
 <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>
 <L3T64FQuUSIrTQvaKgrQIaliuLyGWRWROmsR-2zbJJw=.651a58a0-5015-45d7-97e8-b40361739f7c@github.com>
 <k_L1TnwIOXAazmC4cPBGkYlYIutMqQj-vVesd-oUrA8=.3234cc6e-5097-4729-bc61-ae0d7c72872e@github.com>
Message-ID: <Fjbsj6IZl6ok33LWACeYN1TOkKvF8qzLdhlJYBXMc8Y=.6c57871a-02a7-43e3-b316-fd5932378e54@github.com>

On Wed, 1 Nov 2023 21:31:02 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> These two
>> #define HB_NO_SUBSET_LAYOUT
>> #define HB_NO_SUBSET_CFF
>
> You can find the file here:
> https://github.com/openjdk/jdk/blob/f262f06c97b9ea94cd6119b3a8beb16bf804d083/src/java.desktop/share/native/libharfbuzz/graph/gsubgpos-context.cc
> 
> Hb-subset files are not guarded by ifdefs; HB_NO_SUBSET_LAYOUT only excludes some functions, but not others. I'll check the impact of that define when I'm back in office.
> 
> I checked the list of HB APIs [here](https://harfbuzz.github.io/reference-manual.html) ; hb-subset and hb-style belong to non-core API sets, so I decided to check if hb-style was needed. It was not.
> 
> We can safely stop compiling the files listed because:
> - none of the harfbuzz functions are exported, and they are not accessible outside of libfontmanager.
> - if we excluded any file that was actually used, linker would refuse to link libfontmanager
> 
> Given that we only copy an arbitrary subset of harfbuzz files anyway (see UPDATING.txt), would it make sense to remove these files instead?

FWIW, I compiled the code without this PR, but with `HARFBUZZ_CFLAGS += -DHB_NO_SUBSET_LAYOUT -DHB_NO_SUBSET_CFF` instead, and checked `make LOG=profile` output. Results:
- without this change, compiling `hb-subset.cc` took 56 seconds, and `hb-subset-plan.cc` took 33 seconds
- with this change, compiling `hb-subset.cc` took 33 seconds, and `hb-subset-plan.cc` took 22 seconds

It's a nice improvement, but not compiling these files at all is still much better.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16440#discussion_r1381189047

From duke at openjdk.org  Fri Nov  3 06:19:11 2023
From: duke at openjdk.org (xpbob)
Date: Fri, 3 Nov 2023 06:19:11 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v2]
In-Reply-To: <xdoWyMQ_Gxll_vgtzyru9nFdWgyIx5z63PMwxzNZ-40=.0def34d6-33ea-4772-9708-8be3554c2ed1@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <9-4ZZT_TkGUaqykE_EKa53Jn5hyWw4mbhZiv3VKUy5I=.b331e686-2195-4614-8100-f3e3807e331f@github.com>
 <8Kpx6CBAu3YKxosI4vybK1YmTWIRAav6JdRNSLnt9V4=.2ef36793-5efb-4c56-b4a9-c599f0f45f7f@github.com>
 <wc7a2Nnyiwx04xOKNKqsREr5zWS65dPBr6d0DLUiyl8=.45e462d0-1d85-4649-88ea-a20a430af986@github.com>
 <xdoWyMQ_Gxll_vgtzyru9nFdWgyIx5z63PMwxzNZ-40=.0def34d6-33ea-4772-9708-8be3554c2ed1@github.com>
Message-ID: <NdJHLK40-sItMnmzWzuMA038H3BN9Rjsxf6N5niKUaU=.c8cdb46c-5981-4c41-b6c0-739904a0fa76@github.com>

On Fri, 3 Nov 2023 04:04:49 GMT, Zhao Song <zsong at openjdk.org> wrote:

> > @zhaosongzs Thank you for your suggestions xpbob is my account name, and when I click on profile, the name is empty. I set it up and jcheck worked I have not set a profile since I applied for an account.
> 
> OK, but if you never set your name in your GitHub profile, the jcheck should also fail in your previous PRs. It's weird...


@zhaosongzs 
 I submitted the code back in August and it was fine then
This is a really weird problem,Maybe there are some changes on github

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1791937143

From mbaesken at openjdk.org  Fri Nov  3 07:36:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Nov 2023 07:36:03 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v3]
In-Reply-To: <BBnESqT_-0xu8ZOxSKqB0B2Ku0JP3CMkAvglzGdfLIk=.3a390a0e-feb5-4b7d-bd2e-70ee15689750@github.com>
References: <TV9mDcECvmcX1Rr14VOSOC4xAA4qBZWVZDZWHRXISvE=.bbb1e620-446f-4362-9284-9afee9dfc107@github.com>
 <BBnESqT_-0xu8ZOxSKqB0B2Ku0JP3CMkAvglzGdfLIk=.3a390a0e-feb5-4b7d-bd2e-70ee15689750@github.com>
Message-ID: <PqRJq8scRfj-EmyPCVS_kVFa5FQzfQSJGe6c3fKXGh0=.4bfb3b4e-a77a-4b24-8c95-5f9fb3fdfe3d@github.com>

On Thu, 2 Nov 2023 12:44:28 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> There is an early return in Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c that seems to miss a ReleaseIntArrayElements call.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove JNU_ThrowOutOfMemoryError

Hi Phil,  thanks for the review !

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

PR Comment: https://git.openjdk.org/jdk/pull/16392#issuecomment-1791988728

From mbaesken at openjdk.org  Fri Nov  3 12:35:15 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 3 Nov 2023 12:35:15 GMT
Subject: Integrated: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return
In-Reply-To: <TV9mDcECvmcX1Rr14VOSOC4xAA4qBZWVZDZWHRXISvE=.bbb1e620-446f-4362-9284-9afee9dfc107@github.com>
References: <TV9mDcECvmcX1Rr14VOSOC4xAA4qBZWVZDZWHRXISvE=.bbb1e620-446f-4362-9284-9afee9dfc107@github.com>
Message-ID: <eEAKJeFcSOoccwwpVBCw_cs-AyIi6U7bjdpYI3p-i3g=.192e7089-ef9a-4467-b2d9-08e0984cbc12@github.com>

On Fri, 27 Oct 2023 07:48:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> There is an early return in Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c that seems to miss a ReleaseIntArrayElements call.

This pull request has now been integrated.

Changeset: 81db1721
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81db1721d4fac954003441ca2c3c29b0998d310d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8318955: Add ReleaseIntArrayElements in Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return

Reviewed-by: rschmelter, prr

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

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

From jwaters at openjdk.org  Fri Nov  3 15:13:19 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 3 Nov 2023 15:13:19 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <9I1UnM0ZCBsPQiiGZ-Upz7ZiqCiUHdNHOJK7KTKlwzM=.6a54c57a-ae9c-4205-a501-400a589fa652@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
 <UGmhb3qan1A0F8fjIZWSedcfUSnZOBXE_A4gzxrS1Eo=.61eb98ff-3736-4ab8-af63-813c49e5aaed@github.com>
 <9I1UnM0ZCBsPQiiGZ-Upz7ZiqCiUHdNHOJK7KTKlwzM=.6a54c57a-ae9c-4205-a501-400a589fa652@github.com>
Message-ID: <Px7qwLCMglBwJgV9qsYQjbce6NJzjPkpFE5QI6U6WlM=.8c495192-63fd-42c9-9134-b42d71060b38@github.com>

On Fri, 3 Nov 2023 05:06:22 GMT, Phil Race <prr at openjdk.org> wrote:

> > Actually, I can do you one better, now that I think of it, so I don't have to explains potentially deeply nested and confusing error logs:
> > ```
> > int main() {
> >     goto skip;
> >     int i = 0;
> >     skip:
> >     std::printf("Done\n");
> > }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > C:\Users\vertig0\Downloads>cl.exe -nologo -std:c++14 -permissive- -Fo:goto.o goto.cpp
> > goto.cpp(5): error C2362: initialization of 'c' is skipped by 'goto skip' goto.cpp(6): note: see declaration of 'skip'
> > You simply cannot jump over initialization of a local with a goto in C++, as shown by the Visual C compiler above, does this answer your question?
> 
> It tells me 2 things (1) C++ is awful, because the change you made to silence it is a no-op (2) the changes you are making are really wrong, because C++ is telling us it does not like goto, and you aren't addresssing that

I made the decision to use no-op changes based on the review in https://github.com/openjdk/jdk/pull/15996 at @djelinski's suggestion, because I assumed the best way forward is to make the changes minimally disruptive to client code, is that not what we're aiming for here? The quote-on-quote correct ways to fix this are either to wrap everything in a scope, or rewrite a significant portion of the AWT codebase to remove the gotos, the former is very messy and hard to review (as seen above in one of your earlier reviews), the latter would be difficult to do. Not sure which one you'd prefer?

Side note: What about the jdk.accessibility changes? Are those ok at least?

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1792613348

From prr at openjdk.org  Fri Nov  3 17:09:05 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Nov 2023 17:09:05 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser [v6]
In-Reply-To: <1BYrLZcAv2T9vO8CvraYdqhI2VI7SUoV-vVrU71nQq0=.aa46db33-6ccd-462d-86a8-663378881455@github.com>
References: <BlqH_bm3NmujyboDuwBCSI4pRWn3hdIqMTzYeMTyI98=.d47a6454-3d6f-4633-af53-cbc8d35aa92b@github.com>
 <1BYrLZcAv2T9vO8CvraYdqhI2VI7SUoV-vVrU71nQq0=.aa46db33-6ccd-462d-86a8-663378881455@github.com>
Message-ID: <oc05ZXadMn5fkwmw8nHr_oZnA-tyqkEkctv_x8DztPA=.a5a0f1a0-bd67-4116-892d-8702013376cd@github.com>

On Fri, 20 Oct 2023 09:15:11 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Invoking `setEnabled(false)` on an instance of `JFileChooser` the sub-components are unaffected since the sub-components didn't set/unset enabled explicitly. The fix address the issue and sets the Enabled flag to each sub-components. Along with setting the property to each sub components, the action listeners like mouseClick(Double too) and scroll actions has to be processed based on enabled/disabled property similar to other components. Since `JFilechooser` implementation varies based on LookAndFeel, the same had to be taken care for affected LookAndFeel also. 
>> Note: `JFrame` being top level container handles frame disable using native method which couldn't be the case for `JFileChooser`. For `showDialog/showOpenDialog/showSaveDialog` the fix could be to set the one the enabled property for created single Dialog. But when an instance of `JFileChooser` is created and added to Frame (Without Dialog been created), disabling the `FileChooser` alone had to be done by handling each sub-components and listeners separately.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16068#pullrequestreview-1713174292

From prr at openjdk.org  Fri Nov  3 17:14:20 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Nov 2023 17:14:20 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
Message-ID: <S9dYxB8L8UZp8f9UKpruV1NE4v6nFZxNs-cvGqD7ltQ=.94e2c3c1-4652-4d01-9f82-998989983180@github.com>

On Fri, 3 Nov 2023 04:12:46 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Part II awt_PrintJob.cpp

> > > Actually, I can do you one better, now that I think of it, so I don't have to explains potentially deeply nested and confusing error logs:
> > > ```
> > > int main() {
> > >     goto skip;
> > >     int i = 0;
> > >     skip:
> > >     std::printf("Done\n");
> > > }
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > C:\Users\vertig0\Downloads>cl.exe -nologo -std:c++14 -permissive- -Fo:goto.o goto.cpp
> > > goto.cpp(5): error C2362: initialization of 'c' is skipped by 'goto skip' goto.cpp(6): note: see declaration of 'skip'
> > > You simply cannot jump over initialization of a local with a goto in C++, as shown by the Visual C compiler above, does this answer your question?
> > 
> > 
> > It tells me 2 things (1) C++ is awful, because the change you made to silence it is a no-op (2) the changes you are making are really wrong, because C++ is telling us it does not like goto, and you aren't addresssing that
> 
> I made the decision to use no-op changes based on the review in #15996 at @djelinski's suggestion, because I assumed the best way forward is to make the changes minimally disruptive to client code, is that not what we're aiming for here? The quote-on-quote correct ways to fix this are either to wrap everything in a scope, or rewrite a significant portion of the AWT codebase to remove the gotos, the former is very messy and hard to review (as seen above in one of your earlier reviews), the latter would be difficult to do. Not sure which one you'd prefer?
> 
> Side note: What about the jdk.accessibility changes? Are those ok at least?

So this is "illegal" 

 int main() {
  goto skip;
int i = 0;
 skip:
std::printf("Done\n");
 }

and this is legal ?

 int main() {
  goto skip;
 int i;
 i= 0;
 skip:
std::printf("Done\n");
 }

Honestly, I don't like these changes at all.
Anyone looking at the code after the proposed change would just be itching to undo it unless they knew exactly why it was like that.
I'd prefer to leave the code alone and complain to Microsoft as I can't believe they've interpreted / implemented the C++ spec correctly. 
2nd choice is to re-write without gotos.

PS, yes the A11Y changes are OK.

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1792828679
PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1792829994

From prr at openjdk.org  Fri Nov  3 17:20:09 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 3 Nov 2023 17:20:09 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v5]
In-Reply-To: <JtSABlREhW0PsiyMdZKJXEtrk3TpE75obI05pPrALJQ=.f38e1408-0c46-4d96-b5be-a62156b22cfe@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <JtSABlREhW0PsiyMdZKJXEtrk3TpE75obI05pPrALJQ=.f38e1408-0c46-4d96-b5be-a62156b22cfe@github.com>
Message-ID: <3sXniQonKbOCeSvt-QOGwex6gBr2ANwlRocodyjhjVU=.1520b2bd-3ab2-4123-82be-713d34365eea@github.com>

On Fri, 3 Nov 2023 04:58:24 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unneeded methods

Wait, when did we ever discuss setEnabled() ? I know the comment refers to 3 methods and we observed that but all the discussion and testing has been about the size ones. 
Take any changes to that out of this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1792836975

From dnguyen at openjdk.org  Fri Nov  3 21:10:02 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 3 Nov 2023 21:10:02 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
Message-ID: <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>

On Thu, 26 Oct 2023 10:42:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Synth update

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 875:

> 873:             if( !table.getComponentOrientation().isLeftToRight() ) {
> 874:                 x = getWidthInRightToLeft() - x - cm.getColumn(column).getWidth();
> 875:             }

Suggestion:

        if (column < 0) {
            if (!table.getComponentOrientation().isLeftToRight()) {
                x = getWidthInRightToLeft();
            }
        }
        else if (column >= cm.getColumnCount()) {
            if (table.getComponentOrientation().isLeftToRight() ) {
                x = table.getWidth();
            }
        }
        else {
            for (int i = 0; i < column; i++) {
                x += cm.getColumn(i).getWidth();
            }
            if (!table.getComponentOrientation().isLeftToRight()) {
                x = getWidthInRightToLeft() - x - cm.getColumn(column).getWidth();
            }

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 878:

> 876:         }
> 877:         return x;
> 878:     }

Suggestion:

        if (column < 0) {
            if (!table.getComponentOrientation().isLeftToRight()) {
                x = getWidthInRightToLeft();
            }
        }
        else if (column >= cm.getColumnCount()) {
            if (table.getComponentOrientation().isLeftToRight()) {
                x = table.getWidth();
            }
        }
        else {
            for (int i = 0; i < column; i++) {
                x += cm.getColumn(i).getWidth();
            }
            if (!table.getComponentOrientation().isLeftToRight()) {
                x = getWidthInRightToLeft() - x - cm.getColumn(column).getWidth();
            }
        }
        return x;
    }

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 64:

> 62: 
> 63:     public static void main(String[] args) throws Exception {
> 64:         UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");

Should this test run on all L&F? Since part of the fix occurs in BasicTableUI.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 121:

> 119:     private static void saveImage(BufferedImage image, String fileName) {
> 120:         try {
> 121:             ImageIO.write(image, "png", new File(fileName));

Is it OK to save an image here? In the past, I stored my images similar to in #7310 to store the image in the correct area for temporary images for a test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1382198457
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1382202632
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1382203232
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1382203747

From jwaters at openjdk.org  Sat Nov  4 06:33:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Nov 2023 06:33:03 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v19]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <cdUc21Ov8vO392CYn8xIUCEfmexH0qgYTUIsymK9DVY=.380f91ae-01ce-4d7c-8f51-62207fbddc5a@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

 - Error awt_Canvas.cpp
 - RAII awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/60dbef3c..d33b79a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=17-18

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

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

From jwaters at openjdk.org  Sat Nov  4 06:33:06 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Nov 2023 06:33:06 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <S9dYxB8L8UZp8f9UKpruV1NE4v6nFZxNs-cvGqD7ltQ=.94e2c3c1-4652-4d01-9f82-998989983180@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
 <S9dYxB8L8UZp8f9UKpruV1NE4v6nFZxNs-cvGqD7ltQ=.94e2c3c1-4652-4d01-9f82-998989983180@github.com>
Message-ID: <4DKLXWsmZF2K-Adlhv72RU4a5cKaqQr8N2RkrbPue5A=.81ac9e7e-d459-4f49-82c0-df46ae745cd9@github.com>

On Fri, 3 Nov 2023 17:12:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Part II awt_PrintJob.cpp
>
> PS, yes the A11Y changes are OK.

@prrace I've implemented an RAII strategy in awt_Canvas.cpp as an initial experiment to replace the gotos, if you like it I'll convert the rest to RAII as well

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1793359461

From jwaters at openjdk.org  Sat Nov  4 06:55:00 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Nov 2023 06:55:00 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v20]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <4YWUpkHGDVCxzqaUDfvMagq4jGtUx43vL_mjzYfTY2o=.1120173c-cc82-489c-8d73-635732c8769d@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Error II awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/d33b79a8..69c0d1f6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=18-19

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

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

From jwaters at openjdk.org  Sat Nov  4 15:00:52 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Nov 2023 15:00:52 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v21]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <hlhvHdMgZTu6dqp8_47IfuO088E0N5xAMi2J74zmBzc=.f3faf68c-cb9d-4560-adb3-300c325f7f91@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Fix Errors awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/69c0d1f6..56fb3b0d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=19-20

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

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

From jwaters at openjdk.org  Sat Nov  4 16:45:19 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 4 Nov 2023 16:45:19 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v22]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <agFzIlpTGTTgz_WzunVfL_q1XvlRAQ8xaue-Rkd23L0=.be35e85c-3182-4b14-9b74-c05e27e152c8@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  C++ Standard Library is not allowed awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/56fb3b0d..673cbff4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=20-21

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

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

From jwaters at openjdk.org  Sun Nov  5 07:11:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 5 Nov 2023 07:11:27 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v23]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <_0ydj45QFWlepdvKCAkQF1KwvuQoVHAY6Fc32L-Qcbk=.add732cb-3c57-453d-a3fa-e7edf754c0f4@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Whitespace awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/673cbff4..e30d680b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=21-22

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

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

From jwaters at openjdk.org  Sun Nov  5 07:11:30 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 5 Nov 2023 07:11:30 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v22]
In-Reply-To: <agFzIlpTGTTgz_WzunVfL_q1XvlRAQ8xaue-Rkd23L0=.be35e85c-3182-4b14-9b74-c05e27e152c8@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <agFzIlpTGTTgz_WzunVfL_q1XvlRAQ8xaue-Rkd23L0=.be35e85c-3182-4b14-9b74-c05e27e152c8@github.com>
Message-ID: <-bHmUbHiFQFGWU56PrI2K6VSZiq9FAfN0mqTkWPoB4I=.df765084-435d-454c-9f85-7186b85c7c19@github.com>

On Sat, 4 Nov 2023 16:45:19 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   C++ Standard Library is not allowed awt_Canvas.cpp

By the way, how outdated is the comment that awt.dll should not rely on msvcp.dll? As far as I can tell we now always distribute msvcp.dll in the JDK, and it would help a lot if I could use the C++ Standard Library for this

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1793657361

From jwaters at openjdk.org  Mon Nov  6 04:10:23 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 6 Nov 2023 04:10:23 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <S9dYxB8L8UZp8f9UKpruV1NE4v6nFZxNs-cvGqD7ltQ=.94e2c3c1-4652-4d01-9f82-998989983180@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
 <S9dYxB8L8UZp8f9UKpruV1NE4v6nFZxNs-cvGqD7ltQ=.94e2c3c1-4652-4d01-9f82-998989983180@github.com>
Message-ID: <dBlzAayj8X6rOVgOxZA2CDC1hvhRIWsXvHtZ8MYM8jo=.ca882425-d5bb-4e34-8eb6-2263ef39be36@github.com>

On Fri, 3 Nov 2023 17:12:07 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Part II awt_PrintJob.cpp
>
> PS, yes the A11Y changes are OK.

@prrace By the way, how outdated is the comment that awt.dll should not rely on msvcp.dll? As far as I can tell we now always distribute msvcp.dll in the JDK, and it would help a lot if I could use the C++ Standard Library for this. Or could I statically link the CRT into awt.dll instead, if awt.dll really should not rely on msvcp.dll?

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1794052639

From psadhukhan at openjdk.org  Mon Nov  6 06:22:33 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Nov 2023 06:22:33 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
Message-ID: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>

> javadoc contract for JComponent.setMinimumSize(Dimension) states:
> 
> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
> 
> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
> 
> Fix is made to check if mnimumSize is set and if so, honour it..

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

  Reinstate setEnabled

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15325/files
  - new: https://git.openjdk.org/jdk/pull/15325/files/6a9a1d5a..2733ea66

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

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

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

From psadhukhan at openjdk.org  Mon Nov  6 06:22:35 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 6 Nov 2023 06:22:35 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v5]
In-Reply-To: <3sXniQonKbOCeSvt-QOGwex6gBr2ANwlRocodyjhjVU=.1520b2bd-3ab2-4123-82be-713d34365eea@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <JtSABlREhW0PsiyMdZKJXEtrk3TpE75obI05pPrALJQ=.f38e1408-0c46-4d96-b5be-a62156b22cfe@github.com>
 <3sXniQonKbOCeSvt-QOGwex6gBr2ANwlRocodyjhjVU=.1520b2bd-3ab2-4123-82be-713d34365eea@github.com>
Message-ID: <WfI7D6W3AHCEEc0YZhOucmLN5K65lZ-Rsl4q9pJqKkk=.8894f87d-aa18-4d41-8cf5-5e597bd8872f@github.com>

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

> Wait, when did we ever discuss setEnabled() ? I know the comment refers to 3 methods and we observed that but all the discussion and testing has been about the size ones. Take any changes to that out of this PR.

As discussed, setEnabled needs to be done separately in case...

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1794155764

From abhiscxk at openjdk.org  Mon Nov  6 07:20:21 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 6 Nov 2023 07:20:21 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v8]
In-Reply-To: <v3cC-Xir-wco0UHI_vkkxrrbEIRZwkoCGyiSBsXTpwE=.534088a8-7c80-444f-9c38-a9a199fa1eaa@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <71Kog6sDk_17WiI_9AU1y1zKnFW53V6nupE-bUFbMl8=.c259ed45-06cf-4c9d-8242-0a9fe9a8e333@github.com>
 <v3cC-Xir-wco0UHI_vkkxrrbEIRZwkoCGyiSBsXTpwE=.534088a8-7c80-444f-9c38-a9a199fa1eaa@github.com>
Message-ID: <C0Vpeyf7fCuwbf2zqcK6_sfWHXvUkXdVgGvf1OENRoI=.de419e02-090b-4b19-ad31-3bebc6324e10@github.com>

On Thu, 2 Nov 2023 18:16:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This is definitely an improvement compared to the complete lack of magnified text on hover, but it still doesn't handle custom renderers.
> 
> I've been digging into how this works in Metal but I couldn't figure it out completely. Eventually, it gets to `JList` of the popup, the list returns the renderer component as its child at the specified position ? this is how text from the renderer gets used as the accessible name.
> 
> This should work for Aqua L&F too, all UI classes are derived from `BasicUI`, but for whatever reason it doesn't, and I didn't figure it out unfortunately.
> 
> However, I came up with an alternative solution which handles custom renderers nicely. You can find my version at [commit eee17ca](https://github.com/openjdk/jdk/commit/eee17ca7fc07fb87997040589bde83f5fad9fdea), it shows the changes to your latest version in the PR. You can also view [the diff to jdk/master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:eee17ca7fc07fb87997040589bde83f5fad9fdea).
> 
> Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. I spent quite a lot of time, and it requires even more time to understand how it gets to `JList.AccessibleJList` and `AccessibleJListChild`.

Thanks @aivanov-jdk for your detailed analysis. I will go through the alternate fix you suggested and check the behavior of VoiceOver and will run the CI jobs to ensure there is no regression as such.

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1794210611

From abhiscxk at openjdk.org  Mon Nov  6 09:34:15 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 6 Nov 2023 09:34:15 GMT
Subject: RFR: 4365952: Cannot disable JFileChooser [v6]
In-Reply-To: <1BYrLZcAv2T9vO8CvraYdqhI2VI7SUoV-vVrU71nQq0=.aa46db33-6ccd-462d-86a8-663378881455@github.com>
References: <BlqH_bm3NmujyboDuwBCSI4pRWn3hdIqMTzYeMTyI98=.d47a6454-3d6f-4633-af53-cbc8d35aa92b@github.com>
 <1BYrLZcAv2T9vO8CvraYdqhI2VI7SUoV-vVrU71nQq0=.aa46db33-6ccd-462d-86a8-663378881455@github.com>
Message-ID: <KnJhsYdBrPEhNc7AQMRC309EdslpP6MPQwNnAUtakmg=.adddda48-af22-4f21-ab4a-2793ce080d66@github.com>

On Fri, 20 Oct 2023 09:15:11 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Invoking `setEnabled(false)` on an instance of `JFileChooser` the sub-components are unaffected since the sub-components didn't set/unset enabled explicitly. The fix address the issue and sets the Enabled flag to each sub-components. Along with setting the property to each sub components, the action listeners like mouseClick(Double too) and scroll actions has to be processed based on enabled/disabled property similar to other components. Since `JFilechooser` implementation varies based on LookAndFeel, the same had to be taken care for affected LookAndFeel also. 
>> Note: `JFrame` being top level container handles frame disable using native method which couldn't be the case for `JFileChooser`. For `showDialog/showOpenDialog/showSaveDialog` the fix could be to set the one the enabled property for created single Dialog. But when an instance of `JFileChooser` is created and added to Frame (Without Dialog been created), disabling the `FileChooser` alone had to be done by handling each sub-components and listeners separately.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

LGTM.

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

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16068#pullrequestreview-1714629866

From ihse at openjdk.org  Mon Nov  6 12:30:12 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 6 Nov 2023 12:30:12 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <Fjbsj6IZl6ok33LWACeYN1TOkKvF8qzLdhlJYBXMc8Y=.6c57871a-02a7-43e3-b316-fd5932378e54@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
 <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>
 <L3T64FQuUSIrTQvaKgrQIaliuLyGWRWROmsR-2zbJJw=.651a58a0-5015-45d7-97e8-b40361739f7c@github.com>
 <k_L1TnwIOXAazmC4cPBGkYlYIutMqQj-vVesd-oUrA8=.3234cc6e-5097-4729-bc61-ae0d7c72872e@github.com>
 <Fjbsj6IZl6ok33LWACeYN1TOkKvF8qzLdhlJYBXMc8Y=.6c57871a-02a7-43e3-b316-fd5932378e54@github.com>
Message-ID: <Mt-S0xHNcxCX0kDyg1YqIW_4z88QU9d6mcdgS_lUcNc=.b15f732a-24e9-4496-8bea-e77e462a2871@github.com>

On Fri, 3 Nov 2023 06:06:29 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> You can find the file here:
>> https://github.com/openjdk/jdk/blob/f262f06c97b9ea94cd6119b3a8beb16bf804d083/src/java.desktop/share/native/libharfbuzz/graph/gsubgpos-context.cc
>> 
>> Hb-subset files are not guarded by ifdefs; HB_NO_SUBSET_LAYOUT only excludes some functions, but not others. I'll check the impact of that define when I'm back in office.
>> 
>> I checked the list of HB APIs [here](https://harfbuzz.github.io/reference-manual.html) ; hb-subset and hb-style belong to non-core API sets, so I decided to check if hb-style was needed. It was not.
>> 
>> We can safely stop compiling the files listed because:
>> - none of the harfbuzz functions are exported, and they are not accessible outside of libfontmanager.
>> - if we excluded any file that was actually used, linker would refuse to link libfontmanager
>> 
>> Given that we only copy an arbitrary subset of harfbuzz files anyway (see UPDATING.txt), would it make sense to remove these files instead?
>
> FWIW, I compiled the code without this PR, but with `HARFBUZZ_CFLAGS += -DHB_NO_SUBSET_LAYOUT -DHB_NO_SUBSET_CFF` instead, and checked `make LOG=profile` output. Results:
> - without this change, compiling `hb-subset.cc` took 56 seconds, and `hb-subset-plan.cc` took 33 seconds
> - with this change, compiling `hb-subset.cc` took 33 seconds, and `hb-subset-plan.cc` took 22 seconds
> 
> It's a nice improvement, but not compiling these files at all is still much better.

@djelinski Just curious; what would the effect be to both include this change and setting the NO_* defines?

If all the references to these defines are made in the excluded files then the only reason for doing that would be some kind of information to subsequent readers of the code, but they might also be checked elsewhere, and thus give an additional speedup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16440#discussion_r1383253003

From djelinski at openjdk.org  Mon Nov  6 13:12:09 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 6 Nov 2023 13:12:09 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <Mt-S0xHNcxCX0kDyg1YqIW_4z88QU9d6mcdgS_lUcNc=.b15f732a-24e9-4496-8bea-e77e462a2871@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
 <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>
 <L3T64FQuUSIrTQvaKgrQIaliuLyGWRWROmsR-2zbJJw=.651a58a0-5015-45d7-97e8-b40361739f7c@github.com>
 <k_L1TnwIOXAazmC4cPBGkYlYIutMqQj-vVesd-oUrA8=.3234cc6e-5097-4729-bc61-ae0d7c72872e@github.com>
 <Fjbsj6IZl6ok33LWACeYN1TOkKvF8qzLdhlJYBXMc8Y=.6c57871a-02a7-43e3-b316-fd5932378e54@github.com>
 <Mt-S0xHNcxCX0kDyg1YqIW_4z88QU9d6mcdgS_lUcNc=.b15f732a-24e9-4496-8bea-e77e462a2871@github.com>
Message-ID: <yXgqXOcCvfnoSkLBjhaQbQUC99pgePWmRy6Fqk0_QpU=.1b07ba8b-6411-41f7-8466-637768715680@github.com>

On Mon, 6 Nov 2023 12:26:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> FWIW, I compiled the code without this PR, but with `HARFBUZZ_CFLAGS += -DHB_NO_SUBSET_LAYOUT -DHB_NO_SUBSET_CFF` instead, and checked `make LOG=profile` output. Results:
>> - without this change, compiling `hb-subset.cc` took 56 seconds, and `hb-subset-plan.cc` took 33 seconds
>> - with this change, compiling `hb-subset.cc` took 33 seconds, and `hb-subset-plan.cc` took 22 seconds
>> 
>> It's a nice improvement, but not compiling these files at all is still much better.
>
> @djelinski Just curious; what would the effect be to both include this change and setting the NO_* defines?
> 
> If all the references to these defines are made in the excluded files then the only reason for doing that would be some kind of information to subsequent readers of the code, but they might also be checked elsewhere, and thus give an additional speedup.

HB_NO_SUBSET_CFF is indeed referenced in 2 header files, which are in turn included somewhere else.
I added the defines on top of the excludes, but this resulted in no measurable build time difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16440#discussion_r1383306726

From tr at openjdk.org  Mon Nov  6 13:32:25 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 6 Nov 2023 13:32:25 GMT
Subject: Integrated: 4365952: Cannot disable JFileChooser
In-Reply-To: <BlqH_bm3NmujyboDuwBCSI4pRWn3hdIqMTzYeMTyI98=.d47a6454-3d6f-4633-af53-cbc8d35aa92b@github.com>
References: <BlqH_bm3NmujyboDuwBCSI4pRWn3hdIqMTzYeMTyI98=.d47a6454-3d6f-4633-af53-cbc8d35aa92b@github.com>
Message-ID: <_lQuHjiz0gkKGee5GCIiTbRigWHMP8945ZCNlwV4Gp4=.bdbc41a0-fbde-4e5d-9780-83366132256c@github.com>

On Fri, 6 Oct 2023 05:10:18 GMT, Tejesh R <tr at openjdk.org> wrote:

> Invoking `setEnabled(false)` on an instance of `JFileChooser` the sub-components are unaffected since the sub-components didn't set/unset enabled explicitly. The fix address the issue and sets the Enabled flag to each sub-components. Along with setting the property to each sub components, the action listeners like mouseClick(Double too) and scroll actions has to be processed based on enabled/disabled property similar to other components. Since `JFilechooser` implementation varies based on LookAndFeel, the same had to be taken care for affected LookAndFeel also. 
> Note: `JFrame` being top level container handles frame disable using native method which couldn't be the case for `JFileChooser`. For `showDialog/showOpenDialog/showSaveDialog` the fix could be to set the one the enabled property for created single Dialog. But when an instance of `JFileChooser` is created and added to Frame (Without Dialog been created), disabling the `FileChooser` alone had to be done by handling each sub-components and listeners separately.

This pull request has now been integrated.

Changeset: 96e6e670
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96e6e670b5e2f95b6222091611cd8922022ec4b1
Stats:     216 lines in 9 files changed: 214 ins; 0 del; 2 mod

4365952: Cannot disable JFileChooser

Reviewed-by: prr, abhiscxk

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

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

From djelinski at openjdk.org  Mon Nov  6 13:33:12 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 6 Nov 2023 13:33:12 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <yXgqXOcCvfnoSkLBjhaQbQUC99pgePWmRy6Fqk0_QpU=.1b07ba8b-6411-41f7-8466-637768715680@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
 <mTY-L_-WFZEta6z1I5aOm-rEWC5UCOjBcxjPSLOT8Qk=.fb973c85-9280-4746-b4b8-ae935bef458a@github.com>
 <L3T64FQuUSIrTQvaKgrQIaliuLyGWRWROmsR-2zbJJw=.651a58a0-5015-45d7-97e8-b40361739f7c@github.com>
 <k_L1TnwIOXAazmC4cPBGkYlYIutMqQj-vVesd-oUrA8=.3234cc6e-5097-4729-bc61-ae0d7c72872e@github.com>
 <Fjbsj6IZl6ok33LWACeYN1TOkKvF8qzLdhlJYBXMc8Y=.6c57871a-02a7-43e3-b316-fd5932378e54@github.com>
 <Mt-S0xHNcxCX0kDyg1YqIW_4z88QU9d6mcdgS_lUcNc=.b15f732a-24e9-4496-8bea-e77e462a2871@github.com>
 <yXgqXOcCvfnoSkLBjhaQbQUC99pgePWmRy6Fqk0_QpU=.1b07ba8b-6411-41f7-8466-637768715680@github.com>
Message-ID: <1nLfqJ7lQ-UjVhD-nZCz9zmBhfYtWZWiTE9kjYn3qC8=.93b767e1-55fc-4e66-8195-dc8de0ae9877@github.com>

On Mon, 6 Nov 2023 13:09:08 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> @djelinski Just curious; what would the effect be to both include this change and setting the NO_* defines?
>> 
>> If all the references to these defines are made in the excluded files then the only reason for doing that would be some kind of information to subsequent readers of the code, but they might also be checked elsewhere, and thus give an additional speedup.
>
> HB_NO_SUBSET_CFF is indeed referenced in 2 header files, which are in turn included somewhere else.
> I added the defines on top of the excludes, but this resulted in no measurable build time difference.

Out of curiosity, I tried building with [HB_LEAN](https://github.com/openjdk/jdk/blob/2d4bbf478745e62584420bfdef5a4948edac54ad/src/java.desktop/share/native/libharfbuzz/hb-config.hh#L57), which is a shortcut for "no optional features"; I got a couple of new warnings, and one error (`hb_font_funcs_set_glyph_v_kerning_func` is deprecated since 2.0 and not compiled with HB_LEAN; fortunately its use in hb-jdk-font.cc can be simply commented out). After resolving these problems, fontmanager compiled successfully - but again, no measurable time difference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16440#discussion_r1383335397

From serb at openjdk.org  Mon Nov  6 18:48:40 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 6 Nov 2023 18:48:40 GMT
Subject: RFR: 8319315: Sending a SysexMessage starting with 0xF7 leads to
 JVM crash
In-Reply-To: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
Message-ID: <ncVv6ewG-gQGZJ8P9jncykLCqmofuEBoedUMkS7tQcU=.4e8c01f1-ffa9-49c3-89ba-bf1f3ba64729@github.com>

On Thu, 2 Nov 2023 13:55:41 GMT, Alec Su <duke at openjdk.org> wrote:

> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
> 
> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
> 
> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
> 
> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
> 
> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.

It seems the bug is a duplicate of the next one https://bugs.openjdk.org/browse/JDK-8301310 ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16477#issuecomment-1795911706

From serb at openjdk.org  Mon Nov  6 18:54:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 6 Nov 2023 18:54:53 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
Message-ID: <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>

On Wed, 25 Oct 2023 23:42:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

Since we plan to import it into jdk22, do you have some performance data to share? any positive or negative effects of this migration?

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1795927326

From serb at openjdk.org  Mon Nov  6 18:56:22 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 6 Nov 2023 18:56:22 GMT
Subject: RFR: 8318580 :
 "javax/swing/MultiMonitor/MultimonVImage.java failing with Error. Can't find
 library: /open/test/jdk/java/awt/regtesthelpers" after JDK-8316053
In-Reply-To: <02Ibmd_1aWhnP0fQCk1cpZtrIp5OR--5HxF2alf3RI8=.785f9c15-704b-401a-b538-ef87943a0507@github.com>
References: <02Ibmd_1aWhnP0fQCk1cpZtrIp5OR--5HxF2alf3RI8=.785f9c15-704b-401a-b538-ef87943a0507@github.com>
Message-ID: <5TePwi7Bty84azBqnbU74YoB5zcfPXUNPXAImoGMSkI=.f185dd8d-2fbd-4db9-ad22-0cb6fa958643@github.com>

On Fri, 27 Oct 2023 23:29:19 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> 1) Fixed the @library regtesthelpers file path 
> 2) Added @build PassFailJFrame
> 3) Added a empty line at the end of the file that was missing.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16408#pullrequestreview-1715970794

From aivanov at openjdk.org  Mon Nov  6 19:37:32 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Nov 2023 19:37:32 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <l_szzhdPMTNx9_pjhNz8AnI4R6MwS7nK_eEwa9KUlSg=.47c02209-b753-46db-b9e3-194ff01aaefa@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

Actually, I meant [the opposite thing](https://github.com/openjdk/jdk/pull/15325#pullrequestreview-1594282373): override `setMinimumSize` and `setMaximumSize` *to specify* the behaviour that `JScrollBar` currently has, which is specified by its `getMinimumSize` and `getMaximumSize`.

I ran an app which creates three scrollbars:
* The first one doesn't modify its size;
* The second one sets its min and max size;
* The third one sets its preferred size in addition to min and max.

The resizing behaviour differs between the current implementation and the PR.

Previously, the secondary axis was fixed, when the frame is resized the secondary axis isn't resized, the scroll bar remains at its preferred size. If the preferred size was set, the size along the secondary axis again becomes fixed. If the frame is to a smaller size, the scrollbar gets clipped. If the frame grows larger than the preferred size, the size of the scrollbars is increased.

I guess the idea was to make scrollbar *always* at its preferred size along its secondary axis. But `setPreferredSize` doesn't enforce it.

With the `getMinimumSize` and `getMaximumSize` removed, as in the current state in this PR, the scrollbar becomes flexible along its secondary axis too. Thus, the third scrollbar, which has all three sizes set, accommodates the changes in size: it grows or shrinks as the frame is resized. The second scrollbar starts growing only after the the third one reaches its minimum size; after the second scrollbar reaches its maximum size, the third scrollbar gets clipped.

I'm inclined to keep the current behaviour of `getMinimumSize` and `getMaximumSize` as it gives the most pleasing look to the scrollbar. At this time, it could be too late to modify `setPreferredSize` so that it modifies only the value along its main axis, yet this would give the best appearance in my opinion. Is there any application which uses scrollbars not at its preferred size along the secondary axis?

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1796167220

From aivanov at openjdk.org  Mon Nov  6 19:51:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Nov 2023 19:51:41 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v8]
In-Reply-To: <C0Vpeyf7fCuwbf2zqcK6_sfWHXvUkXdVgGvf1OENRoI=.de419e02-090b-4b19-ad31-3bebc6324e10@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <71Kog6sDk_17WiI_9AU1y1zKnFW53V6nupE-bUFbMl8=.c259ed45-06cf-4c9d-8242-0a9fe9a8e333@github.com>
 <v3cC-Xir-wco0UHI_vkkxrrbEIRZwkoCGyiSBsXTpwE=.534088a8-7c80-444f-9c38-a9a199fa1eaa@github.com>
 <C0Vpeyf7fCuwbf2zqcK6_sfWHXvUkXdVgGvf1OENRoI=.de419e02-090b-4b19-ad31-3bebc6324e10@github.com>
Message-ID: <Uu6LNFV-uxixqF9O_HFOirEW6aBWPqYUm8ABf2cBaKU=.39c3b79a-fa74-4699-b24c-5a0aa91ce3a7@github.com>

On Mon, 6 Nov 2023 07:17:27 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> This is definitely an improvement compared to the complete lack of magnified text on hover, but it still doesn't handle custom renderers.
>> 
>> I've been digging into how this works in Metal but I couldn't figure it out completely. Eventually, it gets to `JList` of the popup, the list returns the renderer component as its child at the specified position ? this is how text from the renderer gets used as the accessible name.
>> 
>> This should work for Aqua L&F too, all UI classes are derived from `BasicUI`, but for whatever reason it doesn't, and I didn't figure it out unfortunately.
>> 
>> However, I came up with an alternative solution which handles custom renderers nicely. You can find my version at [commit eee17ca](https://github.com/openjdk/jdk/commit/eee17ca7fc07fb87997040589bde83f5fad9fdea), it shows the changes to your latest version in the PR. You can also view [the diff to jdk/master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:eee17ca7fc07fb87997040589bde83f5fad9fdea).
>> 
>> Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. I spent quite a lot of time, and it requires even more time to understand how it gets to `JList.AccessibleJList` and `AccessibleJListChild`.
>
>> This is definitely an improvement compared to the complete lack of magnified text on hover, but it still doesn't handle custom renderers.
>> 
>> I've been digging into how this works in Metal but I couldn't figure it out completely. Eventually, it gets to `JList` of the popup, the list returns the renderer component as its child at the specified position ? this is how text from the renderer gets used as the accessible name.
>> 
>> This should work for Aqua L&F too, all UI classes are derived from `BasicUI`, but for whatever reason it doesn't, and I didn't figure it out unfortunately.
>> 
>> However, I came up with an alternative solution which handles custom renderers nicely. You can find my version at [commit eee17ca](https://github.com/openjdk/jdk/commit/eee17ca7fc07fb87997040589bde83f5fad9fdea), it shows the changes to your latest version in the PR. You can also view [the diff to jdk/master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:eee17ca7fc07fb87997040589bde83f5fad9fdea).
>> 
>> Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. I spent quite a lot of time, and it requires even more time to understand how it gets to `JList.AccessibleJList` and `AccessibleJListChild`.
> 
> Thanks @aivanov-jdk for your detailed analysis. I will go through the alternate fix you suggested and check the behavior of VoiceOver and will run the CI jobs to ensure there is no regression as such.

@kumarabhi006 I attached the app that I used for testing to [JDK-8283214](https://bugs.openjdk.org/browse/JDK-8283214): `MagnifierTest.java`

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1796222620

From javalists at cbfiddle.com  Mon Nov  6 19:53:47 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Mon, 6 Nov 2023 11:53:47 -0800
Subject: Container.remove issue
Message-ID: <94F9D340-9FE2-4193-AD7D-7EACE61009E3@cbfiddle.com>

I have experienced a problem related to Container.remove(index).

As this code has been around for a long time, I?m wondering (1) why it does what it does and (2) whether
there is some AWT/Swing design rule that I should be following (but I don?t know of one that would have helped).

The implementation of Container.remove(index) first identifies the component at the specified index in the component list.

It then calls removeNotify on that component and calls removeLayoutComponent on its layout manager.

Only then does it remove the component from the component list.

The problem is that is uses the original index to remove the component from the component list, which
presumes that the previous calls to removeNotify and removeLayoutComponent have not done anything
to alter the component list.

As both of these methods can run arbitrary client code, the presumption seems unwarranted.

In my case, removeNotify eventually was called on a focused text field, which caused the text field
to lose focus, which generated events, and an event handler removed the same component from the
container.

What am I missing?


From prr at openjdk.org  Mon Nov  6 20:09:44 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Nov 2023 20:09:44 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <dBlzAayj8X6rOVgOxZA2CDC1hvhRIWsXvHtZ8MYM8jo=.ca882425-d5bb-4e34-8eb6-2263ef39be36@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
 <S9dYxB8L8UZp8f9UKpruV1NE4v6nFZxNs-cvGqD7ltQ=.94e2c3c1-4652-4d01-9f82-998989983180@github.com>
 <dBlzAayj8X6rOVgOxZA2CDC1hvhRIWsXvHtZ8MYM8jo=.ca882425-d5bb-4e34-8eb6-2263ef39be36@github.com>
Message-ID: <4nQLHdfuUsWY0ZjmUuIchgPhRlDcnIqugGxrfrTVmuM=.66a0d90a-a01a-437b-8f1c-6045fa38a8ff@github.com>

On Mon, 6 Nov 2023 04:06:57 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> By the way, how outdated is the comment that awt.dll should not rely on msvcp.dll? As far as I can tell we now always distribute msvcp.dll in the JDK, and it would help a lot if I could use the C++ Standard Library for this

Do we ? I'm not sure why that is. We've previously tried hard to avoid that.
Eg https://hg.openjdk.org/jdk9/jdk9/rev/f3c96aea372d

We should still stay away from it.

But it doesn't matter because the changes you are making aren't going in the right direction.
The root of the compiler complaints is the gotos isn't it ?
So the code needs to be changed to not use gotos.
But there are hundreds of those. I guess only a few trigger the warnings ?
So your awt_Canvas example should end up looking something like this
WARNING: I just edited in place, haven't built it, haven't tested it, it is to show what the code should look like



void AwtCanvas::_SetEraseBackground(void *param)
{
    JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);
                    
    SetEraseBackgroundStruct *sebs = (SetEraseBackgroundStruct *)param;
    jobject canvas = sebs->canvas;
                    
    if (canvas == NULL) {
        env->ExceptionClear(); 
        JNU_ThrowNullPointerException(env, "canvas");
    } else {            
        PDATA pData = JNI_GET_PDATA(canvas);
        if (pData == NULL) {
            env->DeleteGlobalRef(canvas);
            THROW_NULL_PDATA_IF_NOT_DESTROYED(canvas);
        } else {            
            AwtCanvas *c = (AwtCanvas*)pData;
            c->m_eraseBackground = sebs->doErase;
            c->m_eraseBackgroundOnResize = sebs->doEraseOnResize;
            env->DeleteGlobalRef(canvas);
        }                   
    }                        
    delete sebs;            
}

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1796303631

From aivanov at openjdk.org  Mon Nov  6 20:10:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 6 Nov 2023 20:10:29 GMT
Subject: RFR: 8318580 :
 "javax/swing/MultiMonitor/MultimonVImage.java failing with Error. Can't find
 library: /open/test/jdk/java/awt/regtesthelpers" after JDK-8316053
In-Reply-To: <02Ibmd_1aWhnP0fQCk1cpZtrIp5OR--5HxF2alf3RI8=.785f9c15-704b-401a-b538-ef87943a0507@github.com>
References: <02Ibmd_1aWhnP0fQCk1cpZtrIp5OR--5HxF2alf3RI8=.785f9c15-704b-401a-b538-ef87943a0507@github.com>
Message-ID: <8J5fmK555DcH8OyDMIxEJkk3hHSuFGFERm5uVuLwtjU=.5b5b28a9-e29a-4fcf-a398-e4eb52ded4f1@github.com>

On Fri, 27 Oct 2023 23:29:19 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> 1) Fixed the @library regtesthelpers file path 
> 2) Added @build PassFailJFrame
> 3) Added a empty line at the end of the file that was missing.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16408#pullrequestreview-1716150873

From duke at openjdk.org  Mon Nov  6 20:13:40 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Mon, 6 Nov 2023 20:13:40 GMT
Subject: Integrated: 8318580 :
 "javax/swing/MultiMonitor/MultimonVImage.java failing with Error. Can't find
 library: /open/test/jdk/java/awt/regtesthelpers" after JDK-8316053
In-Reply-To: <02Ibmd_1aWhnP0fQCk1cpZtrIp5OR--5HxF2alf3RI8=.785f9c15-704b-401a-b538-ef87943a0507@github.com>
References: <02Ibmd_1aWhnP0fQCk1cpZtrIp5OR--5HxF2alf3RI8=.785f9c15-704b-401a-b538-ef87943a0507@github.com>
Message-ID: <cMErHMITXPzdf3BZXKZrDuTXBBNchSpHlcUr9kHCWAE=.5555296e-f372-4b34-88a1-7b2cf4454cae@github.com>

On Fri, 27 Oct 2023 23:29:19 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> 1) Fixed the @library regtesthelpers file path 
> 2) Added @build PassFailJFrame
> 3) Added a empty line at the end of the file that was missing.

This pull request has now been integrated.

Changeset: e4803e0c
Author:    lawrence.andrews <lawrence.andrews at oracle.com>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e4803e0cbf00da89b98c8703769edc403bb5055b
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8318580: "javax/swing/MultiMonitor/MultimonVImage.java failing with Error. Can't find library: /open/test/jdk/java/awt/regtesthelpers" after JDK-8316053

Reviewed-by: serb, aivanov

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

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

From serb at openjdk.org  Mon Nov  6 20:56:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 6 Nov 2023 20:56:30 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
Message-ID: <NU3V4HhVGG-uuT4kgIByNcAnguJuR1Omjdun-sH0SZ4=.b5140b38-a494-463a-a27d-2dd0bb9d65af@github.com>

On Sun, 29 Oct 2023 14:29:45 GMT, Alec Su <duke at openjdk.org> wrote:

>> JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.
>> 
>> The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.
>> 
>> 
>> import javax.sound.midi.*;
>> 
>> public class MidiTest {
>>     public static class RawMidiMessage extends MidiMessage {
>>         public RawMidiMessage(byte[] data) {
>>             super(data);
>>         }
>> 
>>         @Override
>>         public Object clone() {
>>             return new RawMidiMessage(this.getMessage());
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         var deviceInfos = MidiSystem.getMidiDeviceInfo();
>>         for (var info : deviceInfos) {
>>             try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
>>                 if (device.getMaxReceivers() != 0) {
>>                     System.out.println("Open MIDI port: " + info.getName());
>>                     device.open();
>>                     Receiver receiver = device.getReceiver();
>>                     // Send two sysex messages at once
>>                     receiver.send(new RawMidiMessage(new byte[]{
>>                             (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
>>                             (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
>>                         }), -1);
>>                     // Send another sysex message
>>                     receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
>>                 }
>>             } catch (MidiUnavailableException e) {
>>                 e.printStackTrace();
>>             }
>>         }
>>     }
>> }
>> 
>> 
>> The expected messages received should be the following three messages
>> 
>> F0 7D 01 F7
>> F0 7D 02 F7
>> F0 7D 03 F7
>> 
>> 
>> But acually four messages was received with the second message repeated twice.
>> 
>> F0 7D 01 F7
>> F0 7D 02 F7
>> F0 7D 03 F7
>> F0 7D 02 F7
>> 
>> 
>> To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buf...
>
> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code cleanup

test/jdk/javax/sound/midi/Devices/OutputBuffer.java line 34:

> 32:  * @comment This test does not fail when the bug occurs. It requires manual
> 33:  *          monitoring of the output.
> 34:  * @requires os.family == "windows"

The test does not use any Windows-specific API, this check can be removed so the code will be covered on all platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16399#discussion_r1383974235

From prr at openjdk.org  Mon Nov  6 21:06:29 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Nov 2023 21:06:29 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <FmHEjky4othL93b_1BOGzfN-BrDQOcWrjCogepxzvT4=.68e7f8d4-dc17-4f02-97ea-905931ce87de@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

So if I have this right,
(1) excluding several unused files from the build saves 60 seconds.
(2) Using the two specific #defines instead saves about 34 seconds.
(3) The two specific #defines on top of the excludes from (1) made no difference
(4) HB_LEAN had no impact either .. I presume you mean  when used on top of (1) as well, which suggests that most of what's in there is cheap to compile.

The build exclusion does however include another couple of files, at least one of which is unrelated, not sure if you ever said
how much that saved, but that presumably accounts for some part of 60 sec vs 34 secs

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

PR Comment: https://git.openjdk.org/jdk/pull/16440#issuecomment-1796430552

From prr at openjdk.org  Mon Nov  6 21:13:36 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Nov 2023 21:13:36 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
Message-ID: <4BEUq2T444DW7RJq0Dy3IMpfoT7DHsWiRFxdGb_tvuc=.35afe82b-0dd9-4878-a2eb-0465be00f182@github.com>

On Sun, 29 Oct 2023 14:29:45 GMT, Alec Su <duke at openjdk.org> wrote:

>> JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.
>> 
>> The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.
>> 
>> 
>> import javax.sound.midi.*;
>> 
>> public class MidiTest {
>>     public static class RawMidiMessage extends MidiMessage {
>>         public RawMidiMessage(byte[] data) {
>>             super(data);
>>         }
>> 
>>         @Override
>>         public Object clone() {
>>             return new RawMidiMessage(this.getMessage());
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         var deviceInfos = MidiSystem.getMidiDeviceInfo();
>>         for (var info : deviceInfos) {
>>             try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
>>                 if (device.getMaxReceivers() != 0) {
>>                     System.out.println("Open MIDI port: " + info.getName());
>>                     device.open();
>>                     Receiver receiver = device.getReceiver();
>>                     // Send two sysex messages at once
>>                     receiver.send(new RawMidiMessage(new byte[]{
>>                             (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
>>                             (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
>>                         }), -1);
>>                     // Send another sysex message
>>                     receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
>>                 }
>>             } catch (MidiUnavailableException e) {
>>                 e.printStackTrace();
>>             }
>>         }
>>     }
>> }
>> 
>> 
>> The expected messages received should be the following three messages
>> 
>> F0 7D 01 F7
>> F0 7D 02 F7
>> F0 7D 03 F7
>> 
>> 
>> But acually four messages was received with the second message repeated twice.
>> 
>> F0 7D 01 F7
>> F0 7D 02 F7
>> F0 7D 03 F7
>> F0 7D 02 F7
>> 
>> 
>> To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buf...
>
> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code cleanup

test/jdk/javax/sound/midi/Devices/OutputBuffer.java line 33:

> 31:  *          is sent again with the next sysex message
> 32:  * @comment This test does not fail when the bug occurs. It requires manual
> 33:  *          monitoring of the output.

The fix seems reasonable. but this test comment is odd. I'm not sure I understand what you can mean by manual monitoring of the output. The test doesn't seem useful unless it can detect failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16399#discussion_r1383994508

From djelinski at openjdk.org  Mon Nov  6 21:36:29 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 6 Nov 2023 21:36:29 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <fMvnThfdMHEEWNubFGE8cq5YdY5r2FTJ6fTLQHCenOo=.4b42b87f-d943-4272-9702-9b84c7eda73b@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

(1) - (4) - that's correct.

My tests were hardly scientific; most of the time I only deleted and recompiled libfontmanager using 8 parallel jobs; the time taken by the recompilation was in the 50-75 seconds range both with and without HB_LEAN.
Without the exclusions, the rebuild of libfontmanager takes ~2 minutes.

File build times from a sample run, taken from build-profile.log:
| file | time without any changes | time with -DHB_NO_SUBSET_LAYOUT -DHB_NO_SUBSET_CFF |
| -- | -- | -- |
hb-subset-cff-common.cc | 7.46s | 2.68s
hb-subset-cff1.cc | 14.06s | 2.47s
hb-subset-cff2.cc | 13.14s | 2.82s
hb-subset-input.cc | 5.70 s | 4.36s
hb-subset-plan.cc | 33.62s | 22.27s
hb-subset.cc | 56.15s | 33.33s
hb-subset-instancer-solver.cc | 4.81s | 2.81s
gsubgpos-context.cc | 11.66s | 7.48s
hb-style.cc | 9.49s | 6.67s

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

PR Comment: https://git.openjdk.org/jdk/pull/16440#issuecomment-1796527076

From serb at openjdk.org  Mon Nov  6 21:46:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 6 Nov 2023 21:46:30 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: <4BEUq2T444DW7RJq0Dy3IMpfoT7DHsWiRFxdGb_tvuc=.35afe82b-0dd9-4878-a2eb-0465be00f182@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
 <4BEUq2T444DW7RJq0Dy3IMpfoT7DHsWiRFxdGb_tvuc=.35afe82b-0dd9-4878-a2eb-0465be00f182@github.com>
Message-ID: <4mxaIfPVLG8XrFEX4c8esFSe_8rPDJ_8uPiygl2f1vc=.34203b0c-6662-4d3a-bd82-2f36917012c1@github.com>

On Mon, 6 Nov 2023 21:10:55 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code cleanup
>
> test/jdk/javax/sound/midi/Devices/OutputBuffer.java line 33:
> 
>> 31:  *          is sent again with the next sysex message
>> 32:  * @comment This test does not fail when the bug occurs. It requires manual
>> 33:  *          monitoring of the output.
> 
> The fix seems reasonable. but this test comment is odd. I'm not sure I understand what you can mean by manual monitoring of the output. The test doesn't seem useful unless it can detect failure.

The test is useful since that is the only test that touches the code path when the buffer for the midi message is reused and the bug can be reproduced. at least it doesn't crash.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16399#discussion_r1384051387

From prr at openjdk.org  Mon Nov  6 23:32:39 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Nov 2023 23:32:39 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
Message-ID: <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>

On Mon, 6 Nov 2023 18:52:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Since we plan to import it into jdk22, do you have some performance data to share? any positive or negative effects of this migration?

There's three phases - (1) startup, (2) warmup and  (3) warmed up performance.

JNI has minimal startup / warmup cost, getting to warmed up performance right away.
So if your app starts up and makes just one call to layout, JNI wins easily.
But if it keeps going, then FFM comes out ahead, even counting that startup /warmup cost.

There's a cost to the first time some code in JDK initialises the core FFM.
If that code happens to be this layout code, it'll see that overhead.
That was somewhere around 75ms on my Mac.
On top of that there's the cost of creating the specific method handles and var handles
I have 11 of these, and the total there is about 35-40ms.

So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac,
but only 35-40ms of that is attributable to the specific needs of layout.

And there is some potential for that code to get faster some day
Also if any of the techniques such as AppCDS, or some day, Leyden condensers, are used then
there is also potential to eliminate much of the warmup cost.

The FFM path then needs to be warmed. 

Once warmed up, FFM is always as fast or faster than JNI. 20% faster is typical as
measured by a small test that just calls layout in a loop. It was tried with varying lengths of string.
For just a single char, FFM was only a little faster, but gets better for longer strings.
Once we start to use layout, we use it a lot, so you reach many thousands of calls very quickly.
Just resizing your UI window causes that. It doesn't take long for FFM to become an overall win.
That includes amortizing the cost of the startup / warmup time.
As well as a microbenchmark, I looked at what it does in an app consisting of a Swing JTextArea displaying
a decent amount of Hindi using an OpenType Indic font on Mac.
That takes just over 16,000 (!) calls to layout to get to fully displayed.
Then if you just resize back and forth in just a few seconds FFM catches up and overtakes
I'll show numbers below - this measure all the FFM+layout costs but nothing else in the app.
It bears out what I said about startup.
"layoutCnt" is the number of calls to the method to do layout on a single run of text.
The numbers look like a lot of calls to layout and you might think that took hours
but this really is just about 20-30 secs of manual resizing to get to one million calls.

JNI
==

layoutCnt=1 total=3ms   <<< JNI very fast to start up
layoutCnt=2 total=3ms
layoutCnt=3 total=3ms
layoutCnt=4 total=4ms
layoutCnt=5 total=4ms
layoutCnt=1000 total=31ms
layoutCnt=2000 total=40ms << 9-10ms per thousand calls (40-31)
layoutCnt=3000 total=51ms
layoutCnt=4000 total=61ms
layoutCnt=5000 total=69ms
layoutCnt=6000 total=77ms
layoutCnt=7000 total=90ms
layoutCnt=8000 total=100ms
layoutCnt=9000 total=113ms
layoutCnt=10000 total=122ms
layoutCnt=11000 total=134ms
layoutCnt=12000 total=150ms
layoutCnt=13000 total=157ms
layoutCnt=14000 total=169ms
layoutCnt=15000 total=181ms
layoutCnt=16000 total=193ms   <<< app fully displayed
...
layoutCnt=250000 total=2450ms <<< rough point at which they are equal
...
layoutCnt=1000000 total=9115ms <<< after 1 million calls FFM is clearly behind
layoutCnt=1001000 total=9124ms << STILL 9-10ms per thousand calls (9124-9115)


FFM
===
layoutCnt=1 total=186ms  << // FFM slow to start up, includes 75ms core FFM, 35-40 varhandles + no JIT yet
layoutCnt=2 total=188ms
layoutCnt=3 total=189ms
layoutCnt=4 total=195ms
layoutCnt=5 total=195ms
layoutCnt=1000 total=269ms
layoutCnt=2000 total=284ms  << 15 ms per thousand calls  (284-269)
layoutCnt=3000 total=301ms
layoutCnt=4000 total=317ms
layoutCnt=5000 total=333ms
layoutCnt=6000 total=348ms
layoutCnt=7000 total=365ms
layoutCnt=8000 total=376ms
layoutCnt=9000 total=388ms
layoutCnt=10000 total=397ms
layoutCnt=11000 total=407ms
layoutCnt=12000 total=419ms
layoutCnt=13000 total=425ms
layoutCnt=14000 total=435ms
layoutCnt=15000 total=444ms
layoutCnt=16000 total=453ms  <<< app fully displayed
...
layoutCnt=250000 total=2426ms <<< rough point at which they are equal
...
layoutCnt=1000000 total=8489ms <<< after 1 million calls FFM is clearly ahead
layoutCnt=1001000 total=8496ms << now about 7 ms per thousand calls (8496-8489)

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1797025476

From prr at openjdk.org  Mon Nov  6 23:39:21 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 6 Nov 2023 23:39:21 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <liN37IPfQIGj7v3lL0k0w9FEAVur_BjAcLKvGKI_59Y=.8450ab3c-458e-4942-9ffb-bb0a0dcbae52@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

OK, let's just go with the exclusion at least for now.
If it becomes a problem on a subsequent upgrade it may need to be changed.
We can also explore other options later.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16440#pullrequestreview-1716521585

From serb at openjdk.org  Tue Nov  7 00:00:29 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Nov 2023 00:00:29 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
 <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>
Message-ID: <evGDJiD-l_-ZWqXrr_49mipBrBBq-bOT4AIw0ZvZziY=.6945f131-afc1-47b6-8f3f-edbe3362fb3b@github.com>

On Mon, 6 Nov 2023 23:28:30 GMT, Phil Race <prr at openjdk.org> wrote:

>So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac,
but only 35-40ms of that is attributable to the specific needs of layout.

That looks unfortunate. I guess if we will start to use ffm in other places we can easily spend of 1 second budget on startup=(

> layoutCnt=16000 total=193ms <<< app fully displayed
vs
> layoutCnt=16000 total=453ms <<< app fully displayed

It looks strange that 16000 calls are not enough to warmup, and the difference is so large.

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1797052585

From prr at openjdk.org  Tue Nov  7 00:40:28 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Nov 2023 00:40:28 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <evGDJiD-l_-ZWqXrr_49mipBrBBq-bOT4AIw0ZvZziY=.6945f131-afc1-47b6-8f3f-edbe3362fb3b@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
 <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>
 <evGDJiD-l_-ZWqXrr_49mipBrBBq-bOT4AIw0ZvZziY=.6945f131-afc1-47b6-8f3f-edbe3362fb3b@github.com>
Message-ID: <0NrUdOATwm9ckjU4JesHN7RnvxUtHm7ugDpJ1GAanUA=.63031f7a-1d91-477d-ac64-63a830c2fba6@github.com>

On Mon, 6 Nov 2023 23:58:11 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac,
> > but only 35-40ms of that is attributable to the specific needs of layout.
> 
> That looks unfortunate. I guess if we will start to use ffm in other places we can easily spend of 1 second budget on startup=(

Yes, this case is sufficiently uncommon, that it is OK, and is a decent way to help us track improvements to FFM.
But it would be another matter to have to do it for however many of our core software loops and AWT window
manager interaction calls we need to get running for a minimal app.

> 
> > layoutCnt=16000 total=193ms <<< app fully displayed
> > vs
> > layoutCnt=16000 total=453ms <<< app fully displayed
> 
> It looks strange that 16000 calls are not enough to warmup, and the difference is so large.

I am not a C2 expert, (not even an amateur), I just assume that it takes a lot of calls to be fully optimized.

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1797086938

From serb at openjdk.org  Tue Nov  7 03:05:40 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 7 Nov 2023 03:05:40 GMT
Subject: RFR: 8318091: Remove empty initIDs functions
In-Reply-To: <BuA0kQNtncYSFuHBggVa58cWo6dhx6O9gH5iMKu7Q8c=.b202fe9b-5d21-411a-9ba8-a83a7f7ae96e@github.com>
References: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
 <X52x54JVuxsHZBU96SwwukaAy61lH7sSYio3kUmH13s=.20b6defa-745c-4c08-867b-c79d48b29c65@github.com>
 <BuA0kQNtncYSFuHBggVa58cWo6dhx6O9gH5iMKu7Q8c=.b202fe9b-5d21-411a-9ba8-a83a7f7ae96e@github.com>
Message-ID: <jnkEmkYH_w6xEYUCkUxt6CBYP9DZ1qBdfJA3OCSzfkM=.479a9709-09f9-49ce-bd3d-457eb8323cad@github.com>

On Fri, 27 Oct 2023 11:01:55 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Button.java line 128:
>> 
>>> 126:     static {
>>> 127:         /* ensure that the necessary native libraries are loaded */
>>> 128:         Toolkit.loadLibraries();
>> 
>> I think it is safer to preserve loading the toolkit libraries: `Button` is a peered component and I can't see any of the peers loads the libraries.
>
> Button extends Component, which loads libraries

another thing to note is that the peers are created by the toolkit which init awt lib on startup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16372#discussion_r1384295575

From psadhukhan at openjdk.org  Tue Nov  7 03:31:31 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 7 Nov 2023 03:31:31 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <Ie91-MDOV9wAiS0cm1UG1MlhxD81mqc-dADZFhrM9CI=.45feb93f-dc88-41fe-a0b8-23656f90e171@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

Can you please attach your testcode in JBS?
I tried with the testcases JScrollBarMinLayout.java and JScrollBarMaxLauout.java resizing the frame and I dont see any difference in layout behaviour of the scrollbars with and without these getXXX methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1797642668

From tr at openjdk.org  Tue Nov  7 04:14:28 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Nov 2023 04:14:28 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
Message-ID: <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>

On Fri, 3 Nov 2023 21:06:07 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Synth update
>
> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 64:
> 
>> 62: 
>> 63:     public static void main(String[] args) throws Exception {
>> 64:         UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
> 
> Should this test run on all L&F? Since part of the fix occurs in BasicTableUI.

I couldn't find a way to generalize the automatic test for all L&F, though I tested all manually.

> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 121:
> 
>> 119:     private static void saveImage(BufferedImage image, String fileName) {
>> 120:         try {
>> 121:             ImageIO.write(image, "png", new File(fileName));
> 
> Is it OK to save an image here? In the past, I stored my images similar to in #7310 to store the image in the correct area for temporary images for a test.

U mean to create a test directory and store image there?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1384348542
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1384349455

From tr at openjdk.org  Tue Nov  7 04:18:55 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 7 Nov 2023 04:18:55 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/dbdc6e29..27d6c769

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

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

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

From jwaters at openjdk.org  Tue Nov  7 04:31:42 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 7 Nov 2023 04:31:42 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v23]
In-Reply-To: <_0ydj45QFWlepdvKCAkQF1KwvuQoVHAY6Fc32L-Qcbk=.add732cb-3c57-453d-a3fa-e7edf754c0f4@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <_0ydj45QFWlepdvKCAkQF1KwvuQoVHAY6Fc32L-Qcbk=.add732cb-3c57-453d-a3fa-e7edf754c0f4@github.com>
Message-ID: <L32huUoxpMbhKWV06U52DwfltUdKCt18KML2ncU44i8=.6ca78f65-0e1c-4f00-867f-a590424b0fc9@github.com>

On Sun, 5 Nov 2023 07:11:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace awt_Canvas.cpp

> But it doesn't matter because the changes you are making aren't going in the right direction.
> The root of the compiler complaints is the gotos isn't it ?
> So the code needs to be changed to not use gotos. I guess you did do that but not in a way I'd endorse

Indeed, I am planning to rewrite it in a way that doesn't use gotos (at least for the areas here where the compiler cannot compile). The reason I asked if the C++ Standard Library could be used is because std::unique_ptr can be used here to very cleanly replace the gotos, with minimal and non-disruptive code changes that would be easy to review, compared to the clunky changes I had to make here (without the C++ Library)

> Do we ? I'm not sure why that is. We've previously tried hard to avoid that. Eg https://hg.openjdk.org/jdk9/jdk9/rev/f3c96aea372d
> 
> We should still stay away from it.

So the dynamic version of the C++ Standard Library (msvcp140.dll) cannot be used. Alright. What if we statically link the C Runtime Libraries to awt.dll instead? This way, not only do we not have to worry all the time about introducing a dependency to msvcp140.dll (as everything is statically linked), but std::unique_ptr also becomes available to use here, and we also wouldn't need to do the std::bad_alloc hack that we currently do too. This is as simple as passing the -MT compiler flag to BUILD_LIBAWT in the Makefile

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1797804764

From duke at openjdk.org  Tue Nov  7 06:42:39 2023
From: duke at openjdk.org (songpv-imt)
Date: Tue, 7 Nov 2023 06:42:39 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v3]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: <3dO2ZETKpIcZD28VPF0Vn3vGBfqaIDiScypPWbbE1lA=.800c2159-cb87-4341-b668-0d44ee75aafb@github.com>

> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
> 
> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)

songpv-imt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination

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

Changes: https://git.openjdk.org/jdk/pull/16396/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=02
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16396/head:pull/16396

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

From duke at openjdk.org  Tue Nov  7 07:51:56 2023
From: duke at openjdk.org (songpv-imt)
Date: Tue, 7 Nov 2023 07:51:56 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v4]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: <SCYb2i_Zadb5rpL0ueL3vZk7sP8gfB6poMhpwV9aVHg=.f4169d20-9566-42c0-90a3-59fe3290fe7f@github.com>

> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
> 
> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)

songpv-imt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination

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

Changes: https://git.openjdk.org/jdk/pull/16396/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16396&range=03
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16396.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16396/head:pull/16396

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

From djelinski at openjdk.org  Tue Nov  7 08:44:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 7 Nov 2023 08:44:42 GMT
Subject: Integrated: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <MFJJ73Lcmayg8jNY1h9cmdpOB48cM8iK15p07jAqW-A=.88d10c4e-aebb-4655-a7ab-41e173a15bc6@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

This pull request has now been integrated.

Changeset: e1cae720
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1cae7203674bc288a63e6fb26f94b20e70c74fd
Stats:     4 lines in 1 file changed: 3 ins; 0 del; 1 mod

8319197: Exclude hb-subset and hb-style from compilation

Reviewed-by: erikj, aivanov, prr

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

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

From djelinski at openjdk.org  Tue Nov  7 08:44:41 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 7 Nov 2023 08:44:41 GMT
Subject: RFR: 8319197: Exclude hb-subset and hb-style from compilation
In-Reply-To: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
References: <7cVeDSLOREgYq4HdTL3VTb1E4VTG413EmJy6iKqUTps=.72a350a2-2b69-4c9b-8210-eec6004f482c@github.com>
Message-ID: <F8NnCyse6XVpi4rNdPdii2gCFIT_b9uX_UbUokkhp34=.edfe1945-59d4-400f-b083-703b32819431@github.com>

On Tue, 31 Oct 2023 21:32:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> hb-subset and hb-style APIs are not used and not exported by libfontmanger. We can cut the compilation time by not compiling the unused files.
> 
> The added exclusions reduce the build time by ~1 minute (~8%) on my machine. This is with harfbuzz 8, with harfbuzz 7 the improvement was ~30 seconds.
> 
> Client libs tests continue to pass.

Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16440#issuecomment-1798045820

From duke at openjdk.org  Tue Nov  7 09:10:02 2023
From: duke at openjdk.org (songpv-imt)
Date: Tue, 7 Nov 2023 09:10:02 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v5]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: <Gt8KjQWyGM50rnJfjJugsCIOdNtKh4wA_WXQzzJ2Nkw=.c36fdf2f-bb39-4417-bf49-80821bd44f86@github.com>

> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
> 
> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)

songpv-imt has updated the pull request incrementally with one additional commit since the last revision:

  Update InterJVMGetDropSuccessTest.java
  Based on description in Chapter "17.4 Memory Model", and specifically chapter "17.4.5 Happens-before Order" of the "The Java? Language Specification", DragSourceDropListener.finished field is accessed from two threads without proper synchronization which may also be possible causing the test to fail. Hence, putting code accessing to DragSourceDropListener.finished into a proper synchronization code block.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16396/files
  - new: https://git.openjdk.org/jdk/pull/16396/files/59cea9fc..909b66a7

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

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

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

From aivanov at openjdk.org  Tue Nov  7 14:15:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Nov 2023 14:15:36 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <Ie91-MDOV9wAiS0cm1UG1MlhxD81mqc-dADZFhrM9CI=.45feb93f-dc88-41fe-a0b8-23656f90e171@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
 <Ie91-MDOV9wAiS0cm1UG1MlhxD81mqc-dADZFhrM9CI=.45feb93f-dc88-41fe-a0b8-23656f90e171@github.com>
Message-ID: <QbzEi7EbbGMVcTkXDdoHH1ZHtdnwDzV-8pZZwNg-aZ8=.f40623c3-2e55-4c03-87bf-3150004df254@github.com>

On Tue, 7 Nov 2023 03:29:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Can you please attach your testcode in JBS? I tried with the testcases JScrollBarMinLayout.java and JScrollBarMaxLauout.java resizing the frame and I dont see any difference in layout behaviour of the scrollbars with and without these getXXX methods.

I should've attached it right away, now `ScrollbarSize.java` is attached to JBS.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1798606082

From itakiguchi at openjdk.org  Tue Nov  7 15:13:35 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 7 Nov 2023 15:13:35 GMT
Subject: RFR: 6928542: Chinese characters in RTF are not decoded [v7]
In-Reply-To: <Kyv1SbJe-ftf4oZUvN1QokUWBN7z5IjSU3uux65Pf7U=.77c78d92-d103-43ee-9b26-cde5bc58681d@github.com>
References: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>
 <LnljyRdKlYGOPwCu_7R7C-nPbbGsfyYf7yk_6pxWKIY=.c4d685db-b16b-4a2a-8711-ad5b4e6bec21@github.com>
 <Kyv1SbJe-ftf4oZUvN1QokUWBN7z5IjSU3uux65Pf7U=.77c78d92-d103-43ee-9b26-cde5bc58681d@github.com>
Message-ID: <AyjGjIa7iABhRB5EhUtlOar3--QRIB6RshiWvpu55Xw=.d4dc5457-4f62-4db3-a99a-42b1efd06fe4@github.com>

On Thu, 26 Oct 2023 12:44:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6928542: Chinese characters in RTF are not decoded
>
> For me the added regression test still fails with the fix in WIndows 10...anything I need to do more as a prerequisite?
> 
> 
> Read data^M
> =========^M
> Gr\\u00fcezi -  Switzerland 0^M
> \\u0082\\u00b1\\u0082\\u00f1\\u0082\\u00c9\\u0082\\u00bf\\u0082\\u00cd - Japanese 128^M
> \\u00be\\u00c8\\u00b3\\u00e7\\u00c7\\u00cf\\u00bc\\u00bc\\u00bf\\u00e4 - Korean 129^M
> \\u00c4\\u00e3\\u00ba\\u00c3 - China 134^M
> \\u00bbO\\u00c6W - Traditional Chinese - Taiwan 136^M
> \\u00e3\\u00e5\\u00e9\\u00e1 \\u00f3\\u00ef\\u00f5 - Greek 161^M
> A\\u00f0a\\u00e7 - Turkish (Tree) 162^M
> \\u00fe - Vietnam currency 163^M
> \\u00f9\\u00c8\\u00d1\\u00ec\\u00e5\\u00c9\\u00ed - Hebrew 177^M
> \\u00e3\\u00d1\\u00cd\\u00c8\\u00c7 - Arabic 178^M
> A\\u00e8i\\u00fb - Lithuanian (Thank you) 186^M
> \\u00c7\\u00e4\\u00f0\\u00e0\\u00e2\\u00f1\\u00f2\\u00e2\\u00f3\\u00e9\\u00f2\\u00e5 - Russian 204^M
> \\u00ca\\u00c7\\u00d1\\u00ca\\u00b4\\u00d5 - Thailand 222^M
> cze\\uc48f - Polish 238^M
> ^M
> Expected data^M
> =============^M
> Gr\\u00fcezi -  Switzerland 0^M
> \\u3053\\u3093\\u306b\\u3061\\u306f - Japanese 128^M
> \\uc548\\ub155\\ud558\\uc138\\uc694 - Korean 129^M
> \\u4f60\\u597d - China 134^M
> \\u81fa\\u7063 - Traditional Chinese - Taiwan 136^M
> \\u03b3\\u03b5\\u03b9\\u03b1 \\u03c3\\u03bf\\u03c5 - Greek 161^M
> A\\u011fa\\u00e7 - Turkish (Tree) 162^M
> \\u20ab - Vietnam currency 163^M
> \\u05e9\\u05b8\\u05c1\\u05dc\\u05d5\\u05b9\\u05dd - Hebrew 177^M
> \\u0645\\u0631\\u062d\\u0628\\u0627 - Arabic 178^M
> A\\u010di\\u016b - Lithuanian (Thank you) 186^M
> \\u0417\\u0434\\u0440\\u0430\\u0432\\u0441\\u0442\\u0432\\u0443\\u0439\\u0442\\u0435 - Russian 204^M
> \\u0e2a\\u0e27\\u0e31\\u0e2a\\u0e14\\u0e35 - Thailand 222^M
> cze\\u015b\\u0107 - Polish 238^M
> ^M
> java.lang.RuntimeException: Test failed^M
>         at RTFReadFontCharsetTest.main(RTFReadFontCharsetTest.java:114)^

Hello @prsadhuk .
Sorry for bad reaction.
I tried to run my testcase on Japanese Windows 10/11.
It worked fine as expected.
Could you show me your windows environment ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13553#issuecomment-1798831955

From duke at openjdk.org  Tue Nov  7 16:20:56 2023
From: duke at openjdk.org (Alec Su)
Date: Tue, 7 Nov 2023 16:20:56 GMT
Subject: RFR: 8319315: Sending a SysexMessage starting with 0xF7 leads to
 JVM crash [v2]
In-Reply-To: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
Message-ID: <CDubG-yh0Mhu9IWlFny2T8hoh6hV5wiaHKTsYj8h97c=.a09af50c-0cf6-4244-b602-adbbed0a1d1c@github.com>

> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
> 
> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
> 
> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
> 
> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
> 
> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.

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

 - Adjust the testcase
 - Add JDK-8301310

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16477/files
  - new: https://git.openjdk.org/jdk/pull/16477/files/6228667b..cdf77943

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

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

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

From duke at openjdk.org  Tue Nov  7 16:20:57 2023
From: duke at openjdk.org (Alec Su)
Date: Tue, 7 Nov 2023 16:20:57 GMT
Subject: RFR: 8319315: Sending a SysexMessage starting with 0xF7 leads to
 JVM crash
In-Reply-To: <ncVv6ewG-gQGZJ8P9jncykLCqmofuEBoedUMkS7tQcU=.4e8c01f1-ffa9-49c3-89ba-bf1f3ba64729@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
 <ncVv6ewG-gQGZJ8P9jncykLCqmofuEBoedUMkS7tQcU=.4e8c01f1-ffa9-49c3-89ba-bf1f3ba64729@github.com>
Message-ID: <PtSQUP74F0cVx2lamqeF7b532qy9Ixeg7IMufyaszMg=.6e5648ab-9c30-4f3b-a485-ee30c10c4893@github.com>

On Mon, 6 Nov 2023 18:45:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
>> 
>> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
>> 
>> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
>> 
>> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
>> 
>> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.
>
> It seems the bug is a duplicate of the next one https://bugs.openjdk.org/browse/JDK-8301310 ?

@mrserb Yes, they are indeed the same bug. I'm sorry for not noticing the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/16477#issuecomment-1799061968

From duke at openjdk.org  Tue Nov  7 16:21:59 2023
From: duke at openjdk.org (Alec Su)
Date: Tue, 7 Nov 2023 16:21:59 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v4]
In-Reply-To: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
Message-ID: <h-aUmZ4vYli3ysINJ-KIDDfV55btO8F5Wukz0ktxtdE=.e6b48551-75b3-494f-9b05-c912720024e3@github.com>

> JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.
> 
> The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.
> 
> 
> import javax.sound.midi.*;
> 
> public class MidiTest {
>     public static class RawMidiMessage extends MidiMessage {
>         public RawMidiMessage(byte[] data) {
>             super(data);
>         }
> 
>         @Override
>         public Object clone() {
>             return new RawMidiMessage(this.getMessage());
>         }
>     }
> 
>     public static void main(String[] args) {
>         var deviceInfos = MidiSystem.getMidiDeviceInfo();
>         for (var info : deviceInfos) {
>             try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
>                 if (device.getMaxReceivers() != 0) {
>                     System.out.println("Open MIDI port: " + info.getName());
>                     device.open();
>                     Receiver receiver = device.getReceiver();
>                     // Send two sysex messages at once
>                     receiver.send(new RawMidiMessage(new byte[]{
>                             (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
>                             (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
>                         }), -1);
>                     // Send another sysex message
>                     receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
>                 }
>             } catch (MidiUnavailableException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
> 
> 
> The expected messages received should be the following three messages
> 
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
> 
> 
> But acually four messages was received with the second message repeated twice.
> 
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
> F0 7D 02 F7
> 
> 
> To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buffer hasn't been freed due to an error.
> 
> It seems that the patch may also resolve JDK-8250667. The extra bytes in the s...

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

  Remove OS check in the test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16399/files
  - new: https://git.openjdk.org/jdk/pull/16399/files/819e2cff..4ae4486b

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

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

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

From duke at openjdk.org  Tue Nov  7 16:22:01 2023
From: duke at openjdk.org (Alec Su)
Date: Tue, 7 Nov 2023 16:22:01 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: <4mxaIfPVLG8XrFEX4c8esFSe_8rPDJ_8uPiygl2f1vc=.34203b0c-6662-4d3a-bd82-2f36917012c1@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
 <4BEUq2T444DW7RJq0Dy3IMpfoT7DHsWiRFxdGb_tvuc=.35afe82b-0dd9-4878-a2eb-0465be00f182@github.com>
 <4mxaIfPVLG8XrFEX4c8esFSe_8rPDJ_8uPiygl2f1vc=.34203b0c-6662-4d3a-bd82-2f36917012c1@github.com>
Message-ID: <qaDCpWySofOiOBvvJo6cOjcUyTd8KGmSf7siquH48O4=.820c58c7-d092-4bdf-a450-182a812de3ff@github.com>

On Mon, 6 Nov 2023 21:43:24 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> test/jdk/javax/sound/midi/Devices/OutputBuffer.java line 33:
>> 
>>> 31:  *          is sent again with the next sysex message
>>> 32:  * @comment This test does not fail when the bug occurs. It requires manual
>>> 33:  *          monitoring of the output.
>> 
>> The fix seems reasonable. but this test comment is odd. I'm not sure I understand what you can mean by manual monitoring of the output. The test doesn't seem useful unless it can detect failure.
>
> The test is useful since that is the only test that touches the code path when the buffer for the midi message is reused and the bug can be reproduced. at least it doesn't crash.

Actually I noticed the bug when I was working on https://github.com/openjdk/jdk/pull/16477. The testcase I added in the PR also triggered the bug. However, the testcase crashes JVM before triggering the bug, so I use another testcase for this PR.

The test case sends the folloing three pieces of sysex message

F0 7D 01 02
F7 03 04
F7 05 06 07 F7


The expected message received should be the following

F0 7D 01 02 03 04 05 06 07 F7


But the acual message received is

F0 7D 01 02 03 04 01 02 05 06 07 F7


Therefore, I'm not sure whether it's better to remove the testcase in this PR or keep it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16399#discussion_r1385189461

From duke at openjdk.org  Tue Nov  7 16:22:04 2023
From: duke at openjdk.org (Alec Su)
Date: Tue, 7 Nov 2023 16:22:04 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: <NU3V4HhVGG-uuT4kgIByNcAnguJuR1Omjdun-sH0SZ4=.b5140b38-a494-463a-a27d-2dd0bb9d65af@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
 <NU3V4HhVGG-uuT4kgIByNcAnguJuR1Omjdun-sH0SZ4=.b5140b38-a494-463a-a27d-2dd0bb9d65af@github.com>
Message-ID: <kO98JSJWPmwDEeQFv5De6ufNplyhuR0znDmKjh4Y1ZM=.3f1a2d15-1dcd-45e7-8837-a623a2f21f54@github.com>

On Mon, 6 Nov 2023 20:53:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code cleanup
>
> test/jdk/javax/sound/midi/Devices/OutputBuffer.java line 34:
> 
>> 32:  * @comment This test does not fail when the bug occurs. It requires manual
>> 33:  *          monitoring of the output.
>> 34:  * @requires os.family == "windows"
> 
> The test does not use any Windows-specific API, this check can be removed so the code will be covered on all platforms.

OK, I removed the check.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16399#discussion_r1385192529

From aivanov at openjdk.org  Tue Nov  7 19:10:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 7 Nov 2023 19:10:44 GMT
Subject: RFR: 8319268: Build failure with GCC8.3.1 after 8313643 [v3]
In-Reply-To: <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
References: <Tn_T-AuYJPQkXSgKb5ia0Y1M_W5gouMqnIfR7IADY24=.8977848a-86c2-4938-960d-98f51962c02c@github.com>
 <hQznijvberLXOdTnBVbWNhz7WeWmpLhlYhfAljXV0l0=.f8437ba5-8ea0-4477-93d8-af3311d81111@github.com>
Message-ID: <IGNACCuY8gdGnXm13bRVq-RjdXxGDR4mqhD2tvKx-i4=.3f6e709a-7378-4a87-9de7-642d58183813@github.com>

On Thu, 2 Nov 2023 14:01:20 GMT, xpbob <duke at openjdk.org> wrote:

>> Build failure with GCC8.3.1
>> 
>> === Output from failing command(s) repeated here ===
>> * For target support_native_java.desktop_libfontmanager_hb-ot-layout.o:
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc: In function 'hb_bool_t hb_ot_layout_get_font_extents(hb_font_t*, hb_direction_t, hb_tag_t, hb_tag_t, hb_font_extents_t*)':
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2136:26: error: 'max' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->ascender = max;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> /data/codes/bobjdk/src/java.desktop/share/native/libharfbuzz/hb-ot-layout.cc:2137:26: error: 'min' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>>        extents->descender = min;
>>        ~~~~~~~~~~~~~~~~~~~^~~~~
>> At global scope:
>> cc1plus: error: unrecognized command line option '-Wno-dangling-reference' [-Werror]
>> cc1plus: all warnings being treated as errors
>> 
>> * All command lines available in /data/codes/bobjdk/build/linux-x86_64-server-release/make-support/failure-logs.
>> === End of repeated output ===
>> 
>> No indication of failed target found.
>> HELP: Try searching the build log for '] Error'.
>> HELP: Run 'make doctor' to diagnose build problems.
>> 
>> make[1]: *** [main] Error 1
>> make: *** [images] Error 2
>
> xpbob has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/modules/java.desktop/lib/Awt2dLibraries.gmk
>   
>   break  up line
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

Interestingly, the build does not fail in CI in mainline without this fix but it fails in jdk21u. I'm backporting [JDK-8313643](https://bugs.openjdk.org/browse/JDK-8313643), and the build fails in CI on Linux x64 with exactly the same error. The compilers used in 21u and mainline are the same. It's weird.

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

PR Comment: https://git.openjdk.org/jdk/pull/16468#issuecomment-1799586417

From duke at openjdk.org  Tue Nov  7 19:37:03 2023
From: duke at openjdk.org (Jan =?UTF-8?B?VHJ1a2VubcO8bGxlcg==?=)
Date: Tue, 7 Nov 2023 19:37:03 GMT
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
Message-ID: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>

The MIDI file parser misinterprets events without status byte when they appear directly after a Meta of SysEx event.

For my bugfix I had to decide between two possible solutions:
- Strict solution: Throw an InvalidMidiDataException
- Tolerant solution: Use the status of the last channel event as running status

I used the tolerant solution.
I will send an email to the list client-libs-dev with my reasons.

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

Commit messages:
 - 8319598: Fixed incorrect interpretation of interrupted running status in SMFParser

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

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

From truj at midica.org  Tue Nov  7 20:32:49 2023
From: truj at midica.org (=?UTF-8?Q?Jan_Trukenm=C3=BCller?=)
Date: Tue, 7 Nov 2023 21:32:49 +0100
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
In-Reply-To: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
References: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
Message-ID: <11241302-e372-4978-83e2-a469844035d2@midica.org>

Am 07.11.23 um 20:37 schrieb Jan Trukenm?ller:
> The MIDI file parser misinterprets events without status byte when they appear directly after a Meta of SysEx event.
> 
> For my bugfix I had to decide between two possible solutions:
> - Strict solution: Throw an InvalidMidiDataException
> - Tolerant solution: Use the status of the last channel event as running status
> 
> I used the tolerant solution.
> I will send an email to the list client-libs-dev with my reasons.
> 
> -------------
> 
> Commit messages:
>   - 8319598: Fixed incorrect interpretation of interrupted running status in SMFParser
> 
> Changes: https://git.openjdk.org/jdk/pull/16546/files
>   Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16546&range=00
>    Issue: https://bugs.openjdk.org/browse/JDK-8319598
>    Stats: 121 lines in 2 files changed: 118 ins; 0 del; 3 mod
>    Patch: https://git.openjdk.org/jdk/pull/16546.diff
>    Fetch: git fetch https://git.openjdk.org/jdk.git pull/16546/head:pull/16546
> 
> PR: https://git.openjdk.org/jdk/pull/16546


Hi,

As I promised, here are my reasons for choosing the tolerant solution.
But first a short description what my PR is about.

Definition:
An "interrupted running status" means:
- In a MIDI file a running status is active
- The next event is a Meta or SysEx event
- The next event does not contain a status byte

Problem:
Files with "interrupted running status" are not parsed correctly.

Possible solutions:
- Strict solution: Throw an InvalidMidiDataException whenever
   an interrupted running status is found
- Tolerant soution: Use the status byte of the last channel
   event with a status byte

Here are 4 reasons for choosing the tolerant solution, sorted from weak 
to strong:


Reason 1:

The SMFParser is very tolerant against even worse violations (e.g. data 
bytes greater than 0x7F, meta data with wrong length and so on)
So I think it is in the spirit of the parser to also allow this minor 
violation.
I think that interrupted running status is only a "minor" violation 
because there is only one sentence in the specification with this 
assumption.
And because there is hardly any other possible interpretation that could 
make sense.


Reason 2:

I tried out a minimal file with interrupted running status with several 
other applications.
The following ones interpret the file like suggested by the tolerant 
solution:

- timidity
- Rosegarden
- Musescore3
- aplaymidi
- Audacious
- midicsv
- JZZ.midi.SMF.js (JZZ.js)
- VLC (with fluidsynth plugin)

The following tools behave differently:

- Pipewire's pw-mididump
   reacts with a segmentation fault
- fluidsynth -a alsa -m alsa_seq -l -i testfile.mid
   Doesn't play the file but returns a successful exit code.
   No error message.
- pmidi
   Error (Meta event 60 not implemented\nUnexpected end of file)

That's 8:3.
And I don't think that the behavior of the 3 is desirable.


Reason 3:

I downloaded a large archive with more than 169.000 MIDI files and did a 
lot of analyses and tests.
First without the bugfix and then with the bugfix.
The results can be summarized like this:

- 1.1% of all MIDI files fail to be loaded by SMFParser (for ANY reason)
- 0.43% of all MIDI files contain interrupted running status
   (maybe some more that have a different problem before the first
   IRS occurs)
- From the files with IRS
   - before the bugfix:
     - 15.67% can be parsed without exception
              (but with incorrectly interpreted data)
     - 69.9% fail with InvalidMidiDataException
     - 14.42% fail with EOFException
   - after the bugfix:
     - 94.2% can be parsed without exception
     - 5.4% fail with InvalidMidiDataException
     - 0.4% fail with EOFException
- The bugfix fixes exceptions for:
   - 78.5% of files with interrupted running status
   - 30.25% of ALL failing MIDI files in general !!!!!
- The bugfix doesn't change anything to any MIDI file without
   interrupted running status

Details:

169457 files are in the archive.
721 contain interrupted running status. (I copied them to a different 
folder to be able to analyze them separately.)

Statistics from (only) the 721 files with interrupted running status:
- before the fix:
   - all:                      721
   - success:                  113
   - InvalidMidiDataException: 504
   - EOFException:             104
- after the fix:
   - all:                      721
   - success:                  679
   - InvalidMidiDataException:  39
   - EOFException:               3

Statistics from ALL files before and after the fix:
- before the fix:
   - all:                       169457
   - success:                   167586
   - fail:                        1871
     - InvalidMidiDataException:  1606
     - EOFException:               265
- after the fix:
   - all:                       169457
   - success:                   168152
   - fail:                        1305
     - InvalidMidiDataException:  1141
     - EOFException:               164


Reason 4:

In a different branch of the JDK I added my bugfix and also a lot of 
debug information to print out several events before and after every 
interrupted running status. I tested this against the 721 files with IRS.
The result was more than 8000 occurrences of IRS, and I looked at each 
of them!
Manually!!!
The vast majority of these occurrences shows very clearly that the data 
makes absolute sense.

However a few of them (maybe 20-30) made no sense at all or were at 
least "suspicious".
So I looked at these remaining files with a hex editor.
In most cases there was a meta message with an incorrect length field or 
something similar, so that the following bytes were interpreted incorrectly.


Conclusion:

After this investigation I'm very confident that the tolerant solution 
is the best.
And isn't it pretty cool to fix 30% of all exceptions with such a simple 
fix?

Best regards
Jan Trukenm?ller
(Github user: truj)

From prr at openjdk.org  Tue Nov  7 22:22:19 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Nov 2023 22:22:19 GMT
Subject: RFR: 8319665: [macOS] Obsolete imports of <Carbon/Carbon.h> in
 java.desktop
Message-ID: <SFqvd-UYU0JLt_zLUN0ZP_xgC889Q1h8chER-TceSuc=.2cebda13-5a68-44b7-898b-e80b55bb53dd@github.com>

Remove unused imports

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

Commit messages:
 - 8319665

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

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

From prr at openjdk.org  Tue Nov  7 22:38:58 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Nov 2023 22:38:58 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v5]
In-Reply-To: <Gt8KjQWyGM50rnJfjJugsCIOdNtKh4wA_WXQzzJ2Nkw=.c36fdf2f-bb39-4417-bf49-80821bd44f86@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <Gt8KjQWyGM50rnJfjJugsCIOdNtKh4wA_WXQzzJ2Nkw=.c36fdf2f-bb39-4417-bf49-80821bd44f86@github.com>
Message-ID: <jXpweexTApQgvoRePAVP205Eexx_SJEywE4-ckmfpYI=.576e9823-4106-4f94-a432-09ede9dec7a0@github.com>

On Tue, 7 Nov 2023 09:10:02 GMT, songpv-imt <duke at openjdk.org> wrote:

>> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
>> 
>> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)
>
> songpv-imt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterJVMGetDropSuccessTest.java
>   Based on description in Chapter "17.4 Memory Model", and specifically chapter "17.4.5 Happens-before Order" of the "The Java? Language Specification", DragSourceDropListener.finished field is accessed from two threads without proper synchronization which may also be possible causing the test to fail. Hence, putting code accessing to DragSourceDropListener.finished into a proper synchronization code block.

Subsequent to submitting a job to verifying this, I've no objection to stability fixes but from what I saw on macOS 14.0 this failed because of some macOS 14 event delivery changes which have been resolved in macOS 14.1

test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 281:

> 279:             boolean success1 = false;
> 280:             synchronized (Util.SYNC_LOCK) {
> 281:                 robot.mouseRelease(InputEvent.BUTTON1_MASK);

In all uses in this file you can change this to BUTTON1_DOWN_MASK since BUTTON1_MASK is deprecated
https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/event/InputEvent.html#BUTTON1_MASK

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

PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1718916499
PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1385676006

From philip.race at oracle.com  Tue Nov  7 22:57:39 2023
From: philip.race at oracle.com (Philip Race)
Date: Tue, 7 Nov 2023 14:57:39 -0800
Subject: Container.remove issue
In-Reply-To: <94F9D340-9FE2-4193-AD7D-7EACE61009E3@cbfiddle.com>
References: <94F9D340-9FE2-4193-AD7D-7EACE61009E3@cbfiddle.com>
Message-ID: <385f1e0a-5af3-4f0c-91eb-a38a7fb6d983@oracle.com>

I don't have a definite answer to your question, and for sure AWT docs 
may be a bit lacking,
but there's also a lot of them so an answer may be buried somewhere.

Not sure if you are saying you are in fact running "arbitrary code" in 
removeNotify() but
I don't think that would be a good idea. You can observe in there but 
I'm not sure
you should "do" anything. Also per the docs you need to call the 
superclass method as the first line.

There's this old bug report https://bugs.openjdk.org/browse/JDK-4074274 
which might be useful to read.

-phil.

On 11/6/23 11:53 AM, Alan Snyder wrote:
> I have experienced a problem related to Container.remove(index).
>
> As this code has been around for a long time, I?m wondering (1) why it does what it does and (2) whether
> there is some AWT/Swing design rule that I should be following (but I don?t know of one that would have helped).
>
> The implementation of Container.remove(index) first identifies the component at the specified index in the component list.
>
> It then calls removeNotify on that component and calls removeLayoutComponent on its layout manager.
>
> Only then does it remove the component from the component list.
>
> The problem is that is uses the original index to remove the component from the component list, which
> presumes that the previous calls to removeNotify and removeLayoutComponent have not done anything
> to alter the component list.
>
> As both of these methods can run arbitrary client code, the presumption seems unwarranted.
>
> In my case, removeNotify eventually was called on a focused text field, which caused the text field
> to lose focus, which generated events, and an event handler removed the same component from the
> container.
>
> What am I missing?
>


From prr at openjdk.org  Tue Nov  7 23:08:56 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 7 Nov 2023 23:08:56 GMT
Subject: RFR: 8319315: Sending a SysexMessage starting with 0xF7 leads to
 JVM crash [v2]
In-Reply-To: <CDubG-yh0Mhu9IWlFny2T8hoh6hV5wiaHKTsYj8h97c=.a09af50c-0cf6-4244-b602-adbbed0a1d1c@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
 <CDubG-yh0Mhu9IWlFny2T8hoh6hV5wiaHKTsYj8h97c=.a09af50c-0cf6-4244-b602-adbbed0a1d1c@github.com>
Message-ID: <SSK8XUc11sxgkUE1INctfLpJVo5rxWXre5rwX7QRgsQ=.91fd6eb2-a6c1-4c41-a986-db58bfc1ef14@github.com>

On Tue, 7 Nov 2023 16:20:56 GMT, Alec Su <duke at openjdk.org> wrote:

>> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
>> 
>> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
>> 
>> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
>> 
>> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
>> 
>> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.
>
> Alec Su has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Adjust the testcase
>  - Add JDK-8301310

rather than adding an issue to the PR, we should close out the duplicate bug and make this PR about the original one.
I'm not sure if skara will fix the PR summary here. If not you'll need to update it manually to 8301310

oh great, I can't even remove the duplicate issue. you'll need to fix this.

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

PR Comment: https://git.openjdk.org/jdk/pull/16477#issuecomment-1800342602

From javalists at cbfiddle.com  Tue Nov  7 23:31:40 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 7 Nov 2023 15:31:40 -0800
Subject: Container.remove issue
In-Reply-To: <385f1e0a-5af3-4f0c-91eb-a38a7fb6d983@oracle.com>
References: <94F9D340-9FE2-4193-AD7D-7EACE61009E3@cbfiddle.com>
 <385f1e0a-5af3-4f0c-91eb-a38a7fb6d983@oracle.com>
Message-ID: <2222AA64-9A66-48A5-A3C0-3507B060198F@cbfiddle.com>


> On Nov 7, 2023, at 2:57?PM, Philip Race <philip.race at oracle.com> wrote:
> 
> I don't have a definite answer to your question, and for sure AWT docs may be a bit lacking,
> but there's also a lot of them so an answer may be buried somewhere.
> 
> Not sure if you are saying you are in fact running "arbitrary code" in removeNotify() but
> I don't think that would be a good idea. You can observe in there but I'm not sure
> you should "do" anything. Also per the docs you need to call the superclass method as the first line.
> 
> There's this old bug report https://bugs.openjdk.org/browse/JDK-4074274 which might be useful to read.
> 
> -phil.
> 


Interesting, but In this case, it is JTextComponent that is ?doing something?.

   public void removeNotify() {
        super.removeNotify();
        if (getFocusedComponent() == this) {
            AppContext.getAppContext().remove(FOCUSED_COMPONENT);
        }
    }

Is there similar advice not to ?do something? in a focus event listener?

I?m not seeing an argument against using some ?defensive programming? in Container.remove.

It would be odd if some application depended upon removing a different component.

  Alan


From duke at openjdk.org  Wed Nov  8 03:36:04 2023
From: duke at openjdk.org (Alec Su)
Date: Wed, 8 Nov 2023 03:36:04 GMT
Subject: RFR: 8319315: Sending a SysexMessage starting with 0xF7 leads to
 JVM crash [v3]
In-Reply-To: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
Message-ID: <j72b7lSQscmjlKXmJlsEkINewoCf2d62NGqqJwiAeRs=.bf9daf41-edf5-4c55-93df-d56143f696a9@github.com>

> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
> 
> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
> 
> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
> 
> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
> 
> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.

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

  Remove JDK-8319315

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16477/files
  - new: https://git.openjdk.org/jdk/pull/16477/files/cdf77943..1b5f6f22

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

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

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

From psadhukhan at openjdk.org  Wed Nov  8 05:08:59 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 05:08:59 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <Z5yQmEntZLhlD3-7rgirgUfahPKCOrttUuFLQZpzNdg=.4d9a620c-2bea-48c0-8d87-fded4501ae94@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

Although there seems to be no difference in rendering the scrollbars with and without these getXXX methods as can be seen here (top one without, bottom one with the methods), 

![image](https://github.com/openjdk/jdk/assets/43534309/2ef18f78-7207-4ceb-b128-5ab77d771950)

I could see difference in behaviour when the frame is resized
and since the premise of the fix is there should not be any difference in behaviour if these methods are removed, I agree that removing the methods as is done in this PR may not be appropriate
but I also think adding setXXX methods in JScrollBar class just to clarify existing spec may also not be appropriate.
In this light, can we consider the previous iteration of the [spec clarification](https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=03#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java) 

@prrace @aivanov-jdk please provide your thoughts..

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1801092478

From tr at openjdk.org  Wed Nov  8 07:38:12 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Nov 2023 07:38:12 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated
Message-ID: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>

`BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

Commit messages:
 - Fix + Manual Test

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

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

From duke at openjdk.org  Wed Nov  8 08:16:58 2023
From: duke at openjdk.org (Jan =?UTF-8?B?VHJ1a2VubcO8bGxlcg==?=)
Date: Wed, 8 Nov 2023 08:16:58 GMT
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
In-Reply-To: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
References: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
Message-ID: <YOkVtsHznaj-Kr2WaT5CgYUQThX-lvVMvjjoojWjSqo=.a4c7db0b-059b-4e68-88c9-1f7869fc78cc@github.com>

On Tue, 7 Nov 2023 19:18:28 GMT, Jan Trukenm?ller <duke at openjdk.org> wrote:

> The MIDI file parser misinterprets events without status byte when they appear directly after a Meta of SysEx event.
> 
> For my bugfix I had to decide between two possible solutions:
> - Strict solution: Throw an InvalidMidiDataException
> - Tolerant solution: Use the status of the last channel event as running status
> 
> I used the tolerant solution.
> I will send an email to the list client-libs-dev with my reasons.

I should not have written my reasons as an Email but directly as a Comment in Github.
Now the statistics part is nearly unreadable.
So only this part again but correctly formatted:

**Summary:**

- 1.1% of all MIDI files fail to be loaded by SMFParser (for ANY reason)
- 0.43% of all MIDI files contain interrupted running status (maybe some more that have a different problem before the first IRS occurs)
- From the files with IRS
  - before the bugfix:
    - 15.67% can be parsed without exception (but with incorrectly interpreted data)
    - 69.9% fail with InvalidMidiDataException
    - 14.42% fail with EOFException
  - after the bugfix:
    - 94.2% can be parsed without exception
    - 5.4% fail with InvalidMidiDataException
    - 0.4% fail with EOFException
- The bugfix fixes exceptions for:
  - 78.5% of files with interrupted running status
  - 30.25% of ALL failing MIDI files in general !!!!!
- The bugfix doesn't change anything to any MIDI file without interrupted running status

**Details:**

Statistics from (only) the 721 files with interrupted running status:
- before the fix:
  - all: 721
  - success: 113
  - InvalidMidiDataException: 504
  - EOFException: 104
- after the fix:
  - all: 721
  - success: 679
  - InvalidMidiDataException: 39
  - EOFException: 3

Statistics from ALL files before and after the fix:
- before the fix:
  - all: 169457
  - success: 167586
  - fail: 1871
    - InvalidMidiDataException: 1606
    - EOFException: 265
- after the fix:
  - all: 169457
  - success: 168152
  - fail: 1305
    - InvalidMidiDataException: 1141
    - EOFException: 164

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

PR Comment: https://git.openjdk.org/jdk/pull/16546#issuecomment-1801289515

From psadhukhan at openjdk.org  Wed Nov  8 08:18:59 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 08:18:59 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <eVwhQ41hhi5FtP42uyJITf84gPe1CTFFWpGc0YTLPUA=.822ae518-13d1-41c9-8b6e-01ede0afea48@github.com>

On Wed, 8 Nov 2023 07:32:52 GMT, Tejesh R <tr at openjdk.org> wrote:

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

src/java.desktop/share/classes/javax/swing/JViewport.java line 618:

> 616:         Graphics bsg = getBackingStoreGraphics(g);
> 617:         try {
> 618:             if (g instanceof SunGraphics2D) {

Can we move the check in `getBackingStoreGraphics` which does not use the passed parameter currently
instead of these 2 places?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1386172643

From psadhukhan at openjdk.org  Wed Nov  8 08:51:59 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 08:51:59 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
Message-ID: <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>

On Tue, 7 Nov 2023 04:18:55 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

> similar to how header is painted

Can you please point to the code where the header is painted similarly?

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

PR Comment: https://git.openjdk.org/jdk/pull/16374#issuecomment-1801342907

From tr at openjdk.org  Wed Nov  8 08:54:17 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Nov 2023 08:54:17 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v2]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <x9i8pURFQjH-fLJr0NP4vl_Ag9Z_pMPE3Z1EvPvGkrw=.3af0f029-bd59-4777-b8d1-a1ef81b73a0e@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/3f795c18..0bfeee34

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

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

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

From tr at openjdk.org  Wed Nov  8 09:02:00 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Nov 2023 09:02:00 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
Message-ID: <TPyY2A-8zRsLnzcdhEIKZ3tph7qEUkCYUWCXo-0Z89E=.9edee9d4-0780-4332-8cb0-63d109d4a3d9@github.com>

On Wed, 8 Nov 2023 08:49:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > similar to how header is painted
> 
> Can you please point to the code where the header is painted similarly?

[HeaderRect](https://github.com/openjdk/jdk/blob/8555e0f6c40c045f7763777a9bf976de99c0534c/src/java.desktop/share/classes/javax/swing/table/JTableHeader.java#L377) is used in [cellRect](https://github.com/openjdk/jdk/blob/8555e0f6c40c045f7763777a9bf976de99c0534c/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableHeaderUI.java#L675) which computes and thus handles the `X position` offset.

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

PR Comment: https://git.openjdk.org/jdk/pull/16374#issuecomment-1801356593

From duke at openjdk.org  Wed Nov  8 09:28:13 2023
From: duke at openjdk.org (songpv-imt)
Date: Wed, 8 Nov 2023 09:28:13 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v6]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: <FyVlQDMdF7tji0yw8dEUI9VMRaqayYv0qhvmth_VywQ=.09f4d384-5deb-4c73-82df-7288707d28d2@github.com>

> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
> 
> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)

songpv-imt has updated the pull request incrementally with one additional commit since the last revision:

  Update InterJVMGetDropSuccessTest.java
  Change BUTTON1_MASK to BUTTON1_DOWN_MASK because BUTTON1_MASK is deprecated: https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/event/InputEvent.html#BUTTON1_MASK

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16396/files
  - new: https://git.openjdk.org/jdk/pull/16396/files/909b66a7..eb667f4e

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

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

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

From duke at openjdk.org  Wed Nov  8 09:28:16 2023
From: duke at openjdk.org (songpv-imt)
Date: Wed, 8 Nov 2023 09:28:16 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v5]
In-Reply-To: <jXpweexTApQgvoRePAVP205Eexx_SJEywE4-ckmfpYI=.576e9823-4106-4f94-a432-09ede9dec7a0@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <Gt8KjQWyGM50rnJfjJugsCIOdNtKh4wA_WXQzzJ2Nkw=.c36fdf2f-bb39-4417-bf49-80821bd44f86@github.com>
 <jXpweexTApQgvoRePAVP205Eexx_SJEywE4-ckmfpYI=.576e9823-4106-4f94-a432-09ede9dec7a0@github.com>
Message-ID: <HK6IwzT8f-U_RMlVyeqrJ3LGz4ZqIorlSMgI9bx4_NE=.edea08fb-3c30-458d-aaa9-984b6f421430@github.com>

On Tue, 7 Nov 2023 22:36:23 GMT, Phil Race <prr at openjdk.org> wrote:

> Subsequent to submitting a job to verifying this, I've no objection to stability fixes but from what I saw on macOS 14.0 this failed because of some macOS 14 event delivery changes which have been resolved in macOS 14.1

Thank you for pointing out the BUTTON1_DOWN_MASK field. I have made the suggested changes. Regarding the issue described in the bug, based on my tests, without the code fix, it actually happens on both macOS 14 and 14.1.

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

PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1801397748

From psadhukhan at openjdk.org  Wed Nov  8 09:34:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 09:34:58 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v2]
In-Reply-To: <x9i8pURFQjH-fLJr0NP4vl_Ag9Z_pMPE3Z1EvPvGkrw=.3af0f029-bd59-4777-b8d1-a1ef81b73a0e@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <x9i8pURFQjH-fLJr0NP4vl_Ag9Z_pMPE3Z1EvPvGkrw=.3af0f029-bd59-4777-b8d1-a1ef81b73a0e@github.com>
Message-ID: <_jPKqamyf-qnhIZKYYu1CMj6QuJSrntxkw_YRyk7G3s=.d1e0edd3-4db5-410e-a25d-38bbdff615dc@github.com>

On Wed, 8 Nov 2023 08:54:17 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 198:

> 196:     }
> 197: 
> 198:     protected void processWindowEvent(WindowEvent e) {

I guess this is not required

Also, please confirm JTable is  getting printed correctly either from existing testcases in javax/swing/JTable and from SwingSet2..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1386272073

From psadhukhan at openjdk.org  Wed Nov  8 09:56:00 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 09:56:00 GMT
Subject: RFR: 6928542: Chinese characters in RTF are not decoded [v7]
In-Reply-To: <LnljyRdKlYGOPwCu_7R7C-nPbbGsfyYf7yk_6pxWKIY=.c4d685db-b16b-4a2a-8711-ad5b4e6bec21@github.com>
References: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>
 <LnljyRdKlYGOPwCu_7R7C-nPbbGsfyYf7yk_6pxWKIY=.c4d685db-b16b-4a2a-8711-ad5b4e6bec21@github.com>
Message-ID: <WzMfVGOZFk3QOsi7FSArAXf9ueyMxJzdXmhjkFjRURQ=.82753f3e-7740-4770-9d6d-f17d5ce3eea0@github.com>

On Thu, 21 Sep 2023 16:21:05 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> "character set of font" (font charset) table was created by "Rich Text Format Specification 1.9.1"
>> https://interoperability.blob.core.windows.net/files/Archive_References/[MSFT-RTF].pdf
>> It refers windgi.h
>> https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-textmetrica
>> 
>> Test files and testcase are in bugid [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542)
>> 
>> Additional change:
>> Special character `\line` should `\n`
>> 
>> Additional information:
>> 
>> Add 2 hash tables
>> - fcharsetToCP: Predefined conversion table, `fcharset` with number control word, from control word to Java charset name, `fcharset0` refers `windows-1252` Java charset name
>> - fcharsetTable: Conversion table for each RTF file, `f` control word with number, from integer font numbers to Charset font charsets, In case of `{\f0\fnil\fcharset0 Segoe UI;}`, `0` refers Java Charset `windows-1252`
>> 
>> When RTF Character Set control word (like `\mac`) is used, unmappable character returns \u0000 and it's not written into RTF text..
>> When fcharset control word is used, unmappable character returns \uFFFD (it's the same as replacement character on decoder), \u0000 is used for DBCS lead byte detection.
>> If `f` or `par` control word is there and lead byte is remains on byte buffer for decoder, this byte data is as invalid character and write \uFFFD into RTF text.
>> 
>> If `f` control word is used without `fcharset`, `translationTable` char array is used.
>> If `f` control word is used with `fcharset`, predefined Java Charset name is used (if missing, ISO8859_1 is used for fallback).
>> 
>> **Note:** Following GitHub actions were failed
>> linux-cross-compile / build (riscv64), I opened following JBS.
>>> [JDK-8314624](https://bugs.openjdk.org/browse/JDK-8314624) GHA: RISC-V cross-build was failed
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6928542: Chinese characters in RTF are not decoded

It was a mistake from my part..It seems to work ok..
LGTM..

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

Marked as reviewed by psadhukhan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13553#pullrequestreview-1719847204

From psadhukhan at openjdk.org  Wed Nov  8 10:11:00 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 10:11:00 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
Message-ID: <ojwV0xz46kQipAhawAopMmKsfvufPS8AMFD9qzo9OmM=.623e636a-c0ce-437b-b2ad-5f7acfc38179@github.com>

On Tue, 7 Nov 2023 04:18:55 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

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

> 2104:                     columnWidth = aColumn.getWidth();
> 2105:                     cellRect.width = columnWidth - columnMargin;
> 2106:                     paintCell(g, cellRect, row, cMax);

Is this code snippet required? It was not needed for LTR..
Guess we do the check in l2113 where we do paintCell for the same..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1386327883

From tr at openjdk.org  Wed Nov  8 10:29:15 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Nov 2023 10:29:15 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/0bfeee34..9f6afa2a

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

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

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

From tr at openjdk.org  Wed Nov  8 10:52:00 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Nov 2023 10:52:00 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v2]
In-Reply-To: <_jPKqamyf-qnhIZKYYu1CMj6QuJSrntxkw_YRyk7G3s=.d1e0edd3-4db5-410e-a25d-38bbdff615dc@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <x9i8pURFQjH-fLJr0NP4vl_Ag9Z_pMPE3Z1EvPvGkrw=.3af0f029-bd59-4777-b8d1-a1ef81b73a0e@github.com>
 <_jPKqamyf-qnhIZKYYu1CMj6QuJSrntxkw_YRyk7G3s=.d1e0edd3-4db5-410e-a25d-38bbdff615dc@github.com>
Message-ID: <R1VXclWTbIzJJR-AXjPBVHqI5wTR-ZdWHmvPJ6lA8SQ=.99ce3d26-53ec-4eba-9aee-12f19d511b74@github.com>

On Wed, 8 Nov 2023 09:30:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 198:
> 
>> 196:     }
>> 197: 
>> 198:     protected void processWindowEvent(WindowEvent e) {
> 
> I guess this is not required
> 
> Also, please confirm JTable is  getting printed correctly either from existing testcases in javax/swing/JTable and from SwingSet2..

Yes, verified with JTable print test cases and SwingSet2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1386429270

From tr at openjdk.org  Wed Nov  8 10:57:58 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Nov 2023 10:57:58 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <ojwV0xz46kQipAhawAopMmKsfvufPS8AMFD9qzo9OmM=.623e636a-c0ce-437b-b2ad-5f7acfc38179@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <ojwV0xz46kQipAhawAopMmKsfvufPS8AMFD9qzo9OmM=.623e636a-c0ce-437b-b2ad-5f7acfc38179@github.com>
Message-ID: <e5pQxqGlpwvvRQ-VdXr5faQ0ow91xk-MyOBro3Z3AZI=.ddb43998-fc7c-4549-a646-a48b3fdaff0a@github.com>

On Wed, 8 Nov 2023 10:08:02 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2106:
> 
>> 2104:                     columnWidth = aColumn.getWidth();
>> 2105:                     cellRect.width = columnWidth - columnMargin;
>> 2106:                     paintCell(g, cellRect, row, cMax);
> 
> Is this code snippet required? It was not needed for LTR..
> Guess we do the check in l2113 where we do paintCell for the same..

Yeah, it maybe to ensure minimum one column is painted/visible during Table drag i.e., meaning when table is shrink to min. But not exactly sure why one column is painted first and then the remaining.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1386436906

From psadhukhan at openjdk.org  Wed Nov  8 11:03:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 11:03:58 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <e5pQxqGlpwvvRQ-VdXr5faQ0ow91xk-MyOBro3Z3AZI=.ddb43998-fc7c-4549-a646-a48b3fdaff0a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <ojwV0xz46kQipAhawAopMmKsfvufPS8AMFD9qzo9OmM=.623e636a-c0ce-437b-b2ad-5f7acfc38179@github.com>
 <e5pQxqGlpwvvRQ-VdXr5faQ0ow91xk-MyOBro3Z3AZI=.ddb43998-fc7c-4549-a646-a48b3fdaff0a@github.com>
Message-ID: <RLbXG8GiKdElK952MVJsRPHAlMqjc4hLLt7kdnRB5qE=.927e0b2a-2beb-4f35-bed6-f2e5fda7315a@github.com>

On Wed, 8 Nov 2023 10:54:59 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2106:
>> 
>>> 2104:                     columnWidth = aColumn.getWidth();
>>> 2105:                     cellRect.width = columnWidth - columnMargin;
>>> 2106:                     paintCell(g, cellRect, row, cMax);
>> 
>> Is this code snippet required? It was not needed for LTR..
>> Guess we do the check in l2113 where we do paintCell for the same..
>
> Yeah, it maybe to ensure minimum one column is painted/visible during Table drag i.e., meaning when table is shrink to min. But not exactly sure why one column is painted first and then the remaining.

Ok..But why it is needed for RTL and not for LTR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1386444024

From tr at openjdk.org  Wed Nov  8 11:20:56 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 8 Nov 2023 11:20:56 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <RLbXG8GiKdElK952MVJsRPHAlMqjc4hLLt7kdnRB5qE=.927e0b2a-2beb-4f35-bed6-f2e5fda7315a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <ojwV0xz46kQipAhawAopMmKsfvufPS8AMFD9qzo9OmM=.623e636a-c0ce-437b-b2ad-5f7acfc38179@github.com>
 <e5pQxqGlpwvvRQ-VdXr5faQ0ow91xk-MyOBro3Z3AZI=.ddb43998-fc7c-4549-a646-a48b3fdaff0a@github.com>
 <RLbXG8GiKdElK952MVJsRPHAlMqjc4hLLt7kdnRB5qE=.927e0b2a-2beb-4f35-bed6-f2e5fda7315a@github.com>
Message-ID: <YnWZACSGPRnTOlSHDflBQn270zpSiA5OwidRtkgrOGE=.711ab224-c8b4-4fe5-b9b2-6a0b9456222e@github.com>

On Wed, 8 Nov 2023 11:01:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yeah, it maybe to ensure minimum one column is painted/visible during Table drag i.e., meaning when table is shrink to min. But not exactly sure why one column is painted first and then the remaining.
>
> Ok..But why it is needed for RTL and not for LTR?

My guess is for RTL the first column might not start from extreme left, as we drag it moves towards the Left corner, this might be for that, still not sure, will verify and come back on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1386462765

From psadhukhan at openjdk.org  Wed Nov  8 13:28:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 13:28:56 GMT
Subject: RFR: 8319665: [macOS] Obsolete imports of <Carbon/Carbon.h> in
 java.desktop
In-Reply-To: <SFqvd-UYU0JLt_zLUN0ZP_xgC889Q1h8chER-TceSuc=.2cebda13-5a68-44b7-898b-e80b55bb53dd@github.com>
References: <SFqvd-UYU0JLt_zLUN0ZP_xgC889Q1h8chER-TceSuc=.2cebda13-5a68-44b7-898b-e80b55bb53dd@github.com>
Message-ID: <Z9rWms_6omlAS1ZcSULTise04ojcmQw5pxZRbkaFPqA=.1d95196a-ae4a-4a00-8e2c-32322ffb5a4a@github.com>

On Tue, 7 Nov 2023 22:14:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove unused imports

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16548#pullrequestreview-1720351230

From psadhukhan at openjdk.org  Wed Nov  8 13:36:03 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 13:36:03 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
Message-ID: <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>

On Wed, 8 Nov 2023 10:29:15 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

src/java.desktop/share/classes/javax/swing/JViewport.java line 607:

> 605: 
> 606:     private Graphics getBackingStoreGraphics(Graphics g) {
> 607:         if (g instanceof SunGraphics2D) {

One thing is the change is not obvious as to why it is being done.
I think we can make the fix more telling by utilizing isPrinting check to make it prominent that the code path is for printing
Suggestion:

       if (!SwingUtilities2.isPrinting(g)) {

Can you see if it works? And yes, you have to make the method public..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1386628386

From psadhukhan at openjdk.org  Wed Nov  8 14:45:00 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 8 Nov 2023 14:45:00 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
Message-ID: <IV0kR0m2Vrk1BbPmJj_w83E3NFb_kcQQccpgrB5NHWc=.125bc407-2d25-425b-a74b-c08b065d5db2@github.com>

On Wed, 8 Nov 2023 10:29:15 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 195:

> 193:             RepaintManager currentManager = RepaintManager.currentManager(c);
> 194:             currentManager.setDoubleBufferingEnabled(true);
> 195:         }

What this is for? I guess it's not needed for this test

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1386731554

From philip.race at oracle.com  Wed Nov  8 18:49:54 2023
From: philip.race at oracle.com (Philip Race)
Date: Wed, 8 Nov 2023 10:49:54 -0800
Subject: Container.remove issue
In-Reply-To: <2222AA64-9A66-48A5-A3C0-3507B060198F@cbfiddle.com>
References: <94F9D340-9FE2-4193-AD7D-7EACE61009E3@cbfiddle.com>
 <385f1e0a-5af3-4f0c-91eb-a38a7fb6d983@oracle.com>
 <2222AA64-9A66-48A5-A3C0-3507B060198F@cbfiddle.com>
Message-ID: <c4695707-96c5-4436-8643-1f85f971239a@oracle.com>

The AppContext.remove() call just removes an entry from a map and 
doesn't affect the UI.
And anyway the caution is about application code doing something.

-phil.

On 11/7/23 3:31 PM, Alan Snyder wrote:
>> On Nov 7, 2023, at 2:57?PM, Philip Race <philip.race at oracle.com> wrote:
>>
>> I don't have a definite answer to your question, and for sure AWT docs may be a bit lacking,
>> but there's also a lot of them so an answer may be buried somewhere.
>>
>> Not sure if you are saying you are in fact running "arbitrary code" in removeNotify() but
>> I don't think that would be a good idea. You can observe in there but I'm not sure
>> you should "do" anything. Also per the docs you need to call the superclass method as the first line.
>>
>> There's this old bug report https://bugs.openjdk.org/browse/JDK-4074274 which might be useful to read.
>>
>> -phil.
>>
>
> Interesting, but In this case, it is JTextComponent that is ?doing something?.
>
>     public void removeNotify() {
>          super.removeNotify();
>          if (getFocusedComponent() == this) {
>              AppContext.getAppContext().remove(FOCUSED_COMPONENT);
>          }
>      }
>
> Is there similar advice not to ?do something? in a focus event listener?
>
> I?m not seeing an argument against using some ?defensive programming? in Container.remove.
>
> It would be odd if some application depended upon removing a different component.
>
>    Alan
>


From serb at openjdk.org  Wed Nov  8 19:19:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Nov 2023 19:19:57 GMT
Subject: RFR: 8319665: [macOS] Obsolete imports of <Carbon/Carbon.h> in
 java.desktop
In-Reply-To: <SFqvd-UYU0JLt_zLUN0ZP_xgC889Q1h8chER-TceSuc=.2cebda13-5a68-44b7-898b-e80b55bb53dd@github.com>
References: <SFqvd-UYU0JLt_zLUN0ZP_xgC889Q1h8chER-TceSuc=.2cebda13-5a68-44b7-898b-e80b55bb53dd@github.com>
Message-ID: <Sscu6yA3oRHmf38q8FWNzFkmLTfEpX4g_bicM0z3-jo=.6834926c-4155-4164-ad54-52a53e3b51f3@github.com>

On Tue, 7 Nov 2023 22:14:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove unused imports

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16548#pullrequestreview-1721100687

From javalists at cbfiddle.com  Wed Nov  8 19:58:43 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Wed, 8 Nov 2023 11:58:43 -0800
Subject: Container.remove issue
In-Reply-To: <c4695707-96c5-4436-8643-1f85f971239a@oracle.com>
References: <94F9D340-9FE2-4193-AD7D-7EACE61009E3@cbfiddle.com>
 <385f1e0a-5af3-4f0c-91eb-a38a7fb6d983@oracle.com>
 <2222AA64-9A66-48A5-A3C0-3507B060198F@cbfiddle.com>
 <c4695707-96c5-4436-8643-1f85f971239a@oracle.com>
Message-ID: <4098FBB3-9968-45EB-ACF1-A22C526012EE@cbfiddle.com>

I stand corrected.

It is Component.removeNotify (called on a text field that is the focus owner) that clears the global
focus owner, triggering a focus changed event.

My point is that my application code is not violating the advice about removeNotify, but
the problem still occurs because my focus event listener is ?doing something?.

Hence my question, is there (or should there be) advice about event listeners not
?doing something??

I still see no reason for Container.remove not to employ defensive programming.
Maybe 20 years ago the performance cost of an extra array reference was considered
a problem, but I can?t see it being a problem today.

  Alan



> On Nov 8, 2023, at 10:49?AM, Philip Race <philip.race at oracle.com> wrote:
> 
> The AppContext.remove() call just removes an entry from a map and doesn't affect the UI.
> And anyway the caution is about application code doing something.
> 
> -phil.
> 
> On 11/7/23 3:31 PM, Alan Snyder wrote:
>>> On Nov 7, 2023, at 2:57?PM, Philip Race <philip.race at oracle.com> wrote:
>>> 
>>> I don't have a definite answer to your question, and for sure AWT docs may be a bit lacking,
>>> but there's also a lot of them so an answer may be buried somewhere.
>>> 
>>> Not sure if you are saying you are in fact running "arbitrary code" in removeNotify() but
>>> I don't think that would be a good idea. You can observe in there but I'm not sure
>>> you should "do" anything. Also per the docs you need to call the superclass method as the first line.
>>> 
>>> There's this old bug report https://bugs.openjdk.org/browse/JDK-4074274 which might be useful to read.
>>> 
>>> -phil.
>>> 
>> 
>> Interesting, but In this case, it is JTextComponent that is ?doing something?.
>> 
>>    public void removeNotify() {
>>         super.removeNotify();
>>         if (getFocusedComponent() == this) {
>>             AppContext.getAppContext().remove(FOCUSED_COMPONENT);
>>         }
>>     }
>> 
>> Is there similar advice not to ?do something? in a focus event listener?
>> 
>> I?m not seeing an argument against using some ?defensive programming? in Container.remove.
>> 
>> It would be odd if some application depended upon removing a different component.
>> 
>>   Alan
>> 
> 


From andy.goryachev at oracle.com  Wed Nov  8 20:21:50 2023
From: andy.goryachev at oracle.com (Andy Goryachev)
Date: Wed, 8 Nov 2023 20:21:50 +0000
Subject: Container.remove issue
In-Reply-To: <4098FBB3-9968-45EB-ACF1-A22C526012EE@cbfiddle.com>
References: <94F9D340-9FE2-4193-AD7D-7EACE61009E3@cbfiddle.com>
 <385f1e0a-5af3-4f0c-91eb-a38a7fb6d983@oracle.com>
 <2222AA64-9A66-48A5-A3C0-3507B060198F@cbfiddle.com>
 <c4695707-96c5-4436-8643-1f85f971239a@oracle.com>
 <4098FBB3-9968-45EB-ACF1-A22C526012EE@cbfiddle.com>
Message-ID: <DM5PR1001MB21724BE38A14A4B4A012DA70E5A8A@DM5PR1001MB2172.namprd10.prod.outlook.com>

As a fellow Swing developer, let me suggest that one should avoid changing the component hierarchy in the middle of another change.  EventQueue.invokeLater() might be a solution to this problem.

Cheers,
-andy



From: client-libs-dev <client-libs-dev-retn at openjdk.org> on behalf of Alan Snyder <javalists at cbfiddle.com>
Date: Wednesday, November 8, 2023 at 11:59
To: Philip Race <philip.race at oracle.com>
Cc: client-libs-dev at openjdk.org <client-libs-dev at openjdk.org>
Subject: Re: Container.remove issue
I stand corrected.

It is Component.removeNotify (called on a text field that is the focus owner) that clears the global
focus owner, triggering a focus changed event.

My point is that my application code is not violating the advice about removeNotify, but
the problem still occurs because my focus event listener is ?doing something?.

Hence my question, is there (or should there be) advice about event listeners not
?doing something??

I still see no reason for Container.remove not to employ defensive programming.
Maybe 20 years ago the performance cost of an extra array reference was considered
a problem, but I can?t see it being a problem today.

  Alan



> On Nov 8, 2023, at 10:49?AM, Philip Race <philip.race at oracle.com> wrote:
>
> The AppContext.remove() call just removes an entry from a map and doesn't affect the UI.
> And anyway the caution is about application code doing something.
>
> -phil.
>
> On 11/7/23 3:31 PM, Alan Snyder wrote:
>>> On Nov 7, 2023, at 2:57?PM, Philip Race <philip.race at oracle.com> wrote:
>>>
>>> I don't have a definite answer to your question, and for sure AWT docs may be a bit lacking,
>>> but there's also a lot of them so an answer may be buried somewhere.
>>>
>>> Not sure if you are saying you are in fact running "arbitrary code" in removeNotify() but
>>> I don't think that would be a good idea. You can observe in there but I'm not sure
>>> you should "do" anything. Also per the docs you need to call the superclass method as the first line.
>>>
>>> There's this old bug report https://bugs.openjdk.org/browse/JDK-4074274 which might be useful to read.
>>>
>>> -phil.
>>>
>>
>> Interesting, but In this case, it is JTextComponent that is ?doing something?.
>>
>>    public void removeNotify() {
>>         super.removeNotify();
>>         if (getFocusedComponent() == this) {
>>             AppContext.getAppContext().remove(FOCUSED_COMPONENT);
>>         }
>>     }
>>
>> Is there similar advice not to ?do something? in a focus event listener?
>>
>> I?m not seeing an argument against using some ?defensive programming? in Container.remove.
>>
>> It would be odd if some application depended upon removing a different component.
>>
>>   Alan
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231108/535f9d16/attachment.htm>

From serb at openjdk.org  Wed Nov  8 21:54:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 8 Nov 2023 21:54:58 GMT
Subject: RFR: 8301310: The SendRawSysexMessage test may cause a JVM crash
 [v3]
In-Reply-To: <j72b7lSQscmjlKXmJlsEkINewoCf2d62NGqqJwiAeRs=.bf9daf41-edf5-4c55-93df-d56143f696a9@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
 <j72b7lSQscmjlKXmJlsEkINewoCf2d62NGqqJwiAeRs=.bf9daf41-edf5-4c55-93df-d56143f696a9@github.com>
Message-ID: <V6OQVqH3INgX9J8KNVz4RzcAN0iekj8ISb5k7ij_R24=.035abb04-e25e-464d-9f33-210b41805398@github.com>

On Wed, 8 Nov 2023 03:36:04 GMT, Alec Su <duke at openjdk.org> wrote:

>> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
>> 
>> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
>> 
>> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
>> 
>> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
>> 
>> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.
>
> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JDK-8319315

test/jdk/javax/sound/midi/SysexMessage/SendRawSysexMessage.java line 126:

> 124:                 r.send(new SysexMessage(new byte[]{
> 125:                         (byte) SPECIAL_SYSTEM_EXCLUSIVE, 0x05, 0x06, 0x07
> 126:                         (byte) SPECIAL_SYSTEM_EXCLUSIVE}, 4), -1);

comma is missed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16477#discussion_r1387239267

From prr at openjdk.org  Wed Nov  8 22:53:03 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 8 Nov 2023 22:53:03 GMT
Subject: Integrated: 8319665: [macOS] Obsolete imports of <Carbon/Carbon.h> in
 java.desktop
In-Reply-To: <SFqvd-UYU0JLt_zLUN0ZP_xgC889Q1h8chER-TceSuc=.2cebda13-5a68-44b7-898b-e80b55bb53dd@github.com>
References: <SFqvd-UYU0JLt_zLUN0ZP_xgC889Q1h8chER-TceSuc=.2cebda13-5a68-44b7-898b-e80b55bb53dd@github.com>
Message-ID: <uS0l5wNQJvikJ3_PE0M6S3L_c7U0WvgKJVbhW14wg7E=.909b9620-0330-4620-8a82-0216b84b1d3c@github.com>

On Tue, 7 Nov 2023 22:14:44 GMT, Phil Race <prr at openjdk.org> wrote:

> Remove unused imports

This pull request has now been integrated.

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

8319665: [macOS] Obsolete imports of <Carbon/Carbon.h> in java.desktop

Reviewed-by: psadhukhan, serb

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

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

From itakiguchi at openjdk.org  Thu Nov  9 01:07:16 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 9 Nov 2023 01:07:16 GMT
Subject: Integrated: 6928542: Chinese characters in RTF are not decoded
In-Reply-To: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>
References: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>
Message-ID: <IUWvMK8knEAvdk9AU4IVmF2ejIB4In734WkFtBEQ2_0=.be2d0f53-8c37-47e2-801e-ed4707e874e0@github.com>

On Thu, 20 Apr 2023 05:47:35 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> "character set of font" (font charset) table was created by "Rich Text Format Specification 1.9.1"
> https://interoperability.blob.core.windows.net/files/Archive_References/[MSFT-RTF].pdf
> It refers windgi.h
> https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-textmetrica
> 
> Test files and testcase are in bugid [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542)
> 
> Additional change:
> Special character `\line` should `\n`
> 
> Additional information:
> 
> Add 2 hash tables
> - fcharsetToCP: Predefined conversion table, `fcharset` with number control word, from control word to Java charset name, `fcharset0` refers `windows-1252` Java charset name
> - fcharsetTable: Conversion table for each RTF file, `f` control word with number, from integer font numbers to Charset font charsets, In case of `{\f0\fnil\fcharset0 Segoe UI;}`, `0` refers Java Charset `windows-1252`
> 
> When RTF Character Set control word (like `\mac`) is used, unmappable character returns \u0000 and it's not written into RTF text..
> When fcharset control word is used, unmappable character returns \uFFFD (it's the same as replacement character on decoder), \u0000 is used for DBCS lead byte detection.
> If `f` or `par` control word is there and lead byte is remains on byte buffer for decoder, this byte data is as invalid character and write \uFFFD into RTF text.
> 
> If `f` control word is used without `fcharset`, `translationTable` char array is used.
> If `f` control word is used with `fcharset`, predefined Java Charset name is used (if missing, ISO8859_1 is used for fallback).
> 
> **Note:** Following GitHub actions were failed
> linux-cross-compile / build (riscv64), I opened following JBS.
>> [JDK-8314624](https://bugs.openjdk.org/browse/JDK-8314624) GHA: RISC-V cross-build was failed

This pull request has now been integrated.

Changeset: a26f7c03
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a26f7c03c72e4efe6d3219d294294c554aebc631
Stats:     286 lines in 3 files changed: 282 ins; 0 del; 4 mod

6928542: Chinese characters in RTF are not decoded

Reviewed-by: prr, psadhukhan

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

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

From itakiguchi at openjdk.org  Thu Nov  9 01:07:14 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Thu, 9 Nov 2023 01:07:14 GMT
Subject: RFR: 6928542: Chinese characters in RTF are not decoded [v7]
In-Reply-To: <Kyv1SbJe-ftf4oZUvN1QokUWBN7z5IjSU3uux65Pf7U=.77c78d92-d103-43ee-9b26-cde5bc58681d@github.com>
References: <mvQtxGEVvgoaIILRAqNsUx6ohWAnQWbANRcDVdBxGIg=.8f3636dc-8380-4a90-a5a1-77b9d69c2521@github.com>
 <LnljyRdKlYGOPwCu_7R7C-nPbbGsfyYf7yk_6pxWKIY=.c4d685db-b16b-4a2a-8711-ad5b4e6bec21@github.com>
 <Kyv1SbJe-ftf4oZUvN1QokUWBN7z5IjSU3uux65Pf7U=.77c78d92-d103-43ee-9b26-cde5bc58681d@github.com>
Message-ID: <BYoI63PTD1D9SxY_MN4JhZh3-x7ZLSiDbVMCfkHd5tU=.05d2cac0-a1b7-4a81-a8a2-979da1530d11@github.com>

On Thu, 26 Oct 2023 12:44:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6928542: Chinese characters in RTF are not decoded
>
> For me the added regression test still fails with the fix in WIndows 10...anything I need to do more as a prerequisite?
> 
> 
> Read data^M
> =========^M
> Gr\\u00fcezi -  Switzerland 0^M
> \\u0082\\u00b1\\u0082\\u00f1\\u0082\\u00c9\\u0082\\u00bf\\u0082\\u00cd - Japanese 128^M
> \\u00be\\u00c8\\u00b3\\u00e7\\u00c7\\u00cf\\u00bc\\u00bc\\u00bf\\u00e4 - Korean 129^M
> \\u00c4\\u00e3\\u00ba\\u00c3 - China 134^M
> \\u00bbO\\u00c6W - Traditional Chinese - Taiwan 136^M
> \\u00e3\\u00e5\\u00e9\\u00e1 \\u00f3\\u00ef\\u00f5 - Greek 161^M
> A\\u00f0a\\u00e7 - Turkish (Tree) 162^M
> \\u00fe - Vietnam currency 163^M
> \\u00f9\\u00c8\\u00d1\\u00ec\\u00e5\\u00c9\\u00ed - Hebrew 177^M
> \\u00e3\\u00d1\\u00cd\\u00c8\\u00c7 - Arabic 178^M
> A\\u00e8i\\u00fb - Lithuanian (Thank you) 186^M
> \\u00c7\\u00e4\\u00f0\\u00e0\\u00e2\\u00f1\\u00f2\\u00e2\\u00f3\\u00e9\\u00f2\\u00e5 - Russian 204^M
> \\u00ca\\u00c7\\u00d1\\u00ca\\u00b4\\u00d5 - Thailand 222^M
> cze\\uc48f - Polish 238^M
> ^M
> Expected data^M
> =============^M
> Gr\\u00fcezi -  Switzerland 0^M
> \\u3053\\u3093\\u306b\\u3061\\u306f - Japanese 128^M
> \\uc548\\ub155\\ud558\\uc138\\uc694 - Korean 129^M
> \\u4f60\\u597d - China 134^M
> \\u81fa\\u7063 - Traditional Chinese - Taiwan 136^M
> \\u03b3\\u03b5\\u03b9\\u03b1 \\u03c3\\u03bf\\u03c5 - Greek 161^M
> A\\u011fa\\u00e7 - Turkish (Tree) 162^M
> \\u20ab - Vietnam currency 163^M
> \\u05e9\\u05b8\\u05c1\\u05dc\\u05d5\\u05b9\\u05dd - Hebrew 177^M
> \\u0645\\u0631\\u062d\\u0628\\u0627 - Arabic 178^M
> A\\u010di\\u016b - Lithuanian (Thank you) 186^M
> \\u0417\\u0434\\u0440\\u0430\\u0432\\u0441\\u0442\\u0432\\u0443\\u0439\\u0442\\u0435 - Russian 204^M
> \\u0e2a\\u0e27\\u0e31\\u0e2a\\u0e14\\u0e35 - Thailand 222^M
> cze\\u015b\\u0107 - Polish 238^M
> ^M
> java.lang.RuntimeException: Test failed^M
>         at RTFReadFontCharsetTest.main(RTFReadFontCharsetTest.java:114)^

@prsadhuk , thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13553#issuecomment-1803002403

From duke at openjdk.org  Thu Nov  9 04:13:21 2023
From: duke at openjdk.org (Alec Su)
Date: Thu, 9 Nov 2023 04:13:21 GMT
Subject: RFR: 8301310: The SendRawSysexMessage test may cause a JVM crash
 [v4]
In-Reply-To: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
Message-ID: <6UgLqs_DrdYFzPs2Sx0ppiI3LtbX8tSADojhK8c7eA8=.23cb1c53-811d-4ec4-a0ee-8982703d91ce@github.com>

> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
> 
> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
> 
> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
> 
> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
> 
> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.

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

  Fix an error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16477/files
  - new: https://git.openjdk.org/jdk/pull/16477/files/1b5f6f22..0f1f95a4

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

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

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

From duke at openjdk.org  Thu Nov  9 04:13:22 2023
From: duke at openjdk.org (Alec Su)
Date: Thu, 9 Nov 2023 04:13:22 GMT
Subject: RFR: 8301310: The SendRawSysexMessage test may cause a JVM crash
 [v3]
In-Reply-To: <V6OQVqH3INgX9J8KNVz4RzcAN0iekj8ISb5k7ij_R24=.035abb04-e25e-464d-9f33-210b41805398@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
 <j72b7lSQscmjlKXmJlsEkINewoCf2d62NGqqJwiAeRs=.bf9daf41-edf5-4c55-93df-d56143f696a9@github.com>
 <V6OQVqH3INgX9J8KNVz4RzcAN0iekj8ISb5k7ij_R24=.035abb04-e25e-464d-9f33-210b41805398@github.com>
Message-ID: <LyW62NTZlq0UUGc8TfWMoBVr1tjxhjyr52ytjA3NZCw=.89a814d0-3e4a-4503-afac-12fb682758c1@github.com>

On Wed, 8 Nov 2023 21:51:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove JDK-8319315
>
> test/jdk/javax/sound/midi/SysexMessage/SendRawSysexMessage.java line 126:
> 
>> 124:                 r.send(new SysexMessage(new byte[]{
>> 125:                         (byte) SPECIAL_SYSTEM_EXCLUSIVE, 0x05, 0x06, 0x07
>> 126:                         (byte) SPECIAL_SYSTEM_EXCLUSIVE}, 4), -1);
> 
> comma is missed?

Fixed. I apologize for the stupid mistake.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16477#discussion_r1387461351

From abhiscxk at openjdk.org  Thu Nov  9 04:39:32 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 9 Nov 2023 04:39:32 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>

> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
> 
> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
> 
> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
> 
> CI link is posted in JBS.

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

  Fix for custom renderer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14497/files
  - new: https://git.openjdk.org/jdk/pull/14497/files/1a48076b..3191a277

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

  Stats: 46 lines in 3 files changed: 27 ins; 8 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14497.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14497/head:pull/14497

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

From abhiscxk at openjdk.org  Thu Nov  9 04:39:32 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 9 Nov 2023 04:39:32 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v8]
In-Reply-To: <Uu6LNFV-uxixqF9O_HFOirEW6aBWPqYUm8ABf2cBaKU=.39c3b79a-fa74-4699-b24c-5a0aa91ce3a7@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <71Kog6sDk_17WiI_9AU1y1zKnFW53V6nupE-bUFbMl8=.c259ed45-06cf-4c9d-8242-0a9fe9a8e333@github.com>
 <v3cC-Xir-wco0UHI_vkkxrrbEIRZwkoCGyiSBsXTpwE=.534088a8-7c80-444f-9c38-a9a199fa1eaa@github.com>
 <C0Vpeyf7fCuwbf2zqcK6_sfWHXvUkXdVgGvf1OENRoI=.de419e02-090b-4b19-ad31-3bebc6324e10@github.com>
 <Uu6LNFV-uxixqF9O_HFOirEW6aBWPqYUm8ABf2cBaKU=.39c3b79a-fa74-4699-b24c-5a0aa91ce3a7@github.com>
Message-ID: <WFqVTRh4NA68x17XnSDb-ZiasW2nRmsI8zV8O2Oph4Y=.149c6602-f459-471d-86b8-4b30f9e4c77c@github.com>

On Mon, 6 Nov 2023 19:49:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> This is definitely an improvement compared to the complete lack of magnified text on hover, but it still doesn't handle custom renderers.
>>> 
>>> I've been digging into how this works in Metal but I couldn't figure it out completely. Eventually, it gets to `JList` of the popup, the list returns the renderer component as its child at the specified position ? this is how text from the renderer gets used as the accessible name.
>>> 
>>> This should work for Aqua L&F too, all UI classes are derived from `BasicUI`, but for whatever reason it doesn't, and I didn't figure it out unfortunately.
>>> 
>>> However, I came up with an alternative solution which handles custom renderers nicely. You can find my version at [commit eee17ca](https://github.com/openjdk/jdk/commit/eee17ca7fc07fb87997040589bde83f5fad9fdea), it shows the changes to your latest version in the PR. You can also view [the diff to jdk/master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:eee17ca7fc07fb87997040589bde83f5fad9fdea).
>>> 
>>> Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. I spent quite a lot of time, and it requires even more time to understand how it gets to `JList.AccessibleJList` and `AccessibleJListChild`.
>> 
>> Thanks @aivanov-jdk for your detailed analysis. I will go through the alternate fix you suggested and check the behavior of VoiceOver and will run the CI jobs to ensure there is no regression as such.
>
> @kumarabhi006 I attached the app that I used for testing to [JDK-8283214](https://bugs.openjdk.org/browse/JDK-8283214): `MagnifierTest.java`

@aivanov-jdk I tested with your suggested solution and it looks good to me. Observed a test failure (regression) while running the CI jobs with the fix. Modified the test to fix the issue.
Now, CI jobs are ok. Please review.

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1803149749

From aivanov at openjdk.org  Thu Nov  9 15:54:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Nov 2023 15:54:29 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
Message-ID: <ErAFMrXRO1k79ZKj5a9WsTiq4K2sF3UJD-7W8-75eRc=.ad08e29b-46a6-49f4-bf41-6e21cbcc00ae@github.com>

On Thu, 9 Nov 2023 04:39:32 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
>> 
>> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
>> 
>> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for custom renderer

Changes requested by aivanov (Reviewer).

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 201:

> 199:     }
> 200: 
> 201:     final Component getRendererComponent() {

Suggestion:

    private Component getRendererComponent() {


I wanted to use this method in `AquaComboBoxUI` but eventually I added `updateAccessibleName` instead, thus this method can be made `private`.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 143:

> 141:             public void itemStateChanged(final ItemEvent e) {
> 142: 
> 143:                 if (e.getStateChange() != ItemEvent.SELECTED) return;

Suggestion:

            public void itemStateChanged(final ItemEvent e) {
                if (e.getStateChange() != ItemEvent.SELECTED) return;

The blank line at the start of the method isn't necessary, is it?

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 1:

> 1: /*

You can use HTML for instructions and builder pattern for configuring `PassFailJFrame` if you like. I'm just advertising new features.

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 31:

> 29:  * @requires (os.family == "mac")
> 30:  * @summary Verifies if JComboBox selected item magnifies using
> 31:  * screen magnifier a11y tool.

Suggestion:

 * @summary Verifies if item selected in JComboBox magnifies using
 *          screen magnifier a11y tool

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 48:

> 46:     private static JFrame frame;
> 47:     private static final String INSTRUCTIONS =
> 48:             "1) Enable Screen magnifier on the Mac \n\n" +

Suggestion:

            "1) Enable Screen magnifier on the Mac\n\n" +

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 52:

> 50:                 "Select \"Enable Hover Text\"\n\n" +
> 51:             "2) Move the mouse over the combobox selected item by pressing  " +
> 52:                 "\"command\" button.\n\n" +

Suggestion:

            "2) Move the mouse over the combo box and press  " +
                ""Command" button.\n\n" +

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 53:

> 51:             "2) Move the mouse over the combobox selected item by pressing  " +
> 52:                 "\"command\" button.\n\n" +
> 53:             "3) If magnified label is visible, Press Pass else Fail.";

Suggestion:

            "3) If magnified label is visible, press Pass else Fail.";

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 68:

> 66: 
> 67:         String[] fruits = new String[] {"Apple", "Orange",
> 68:                 "Mango", "Pine Apple", "Banana"};

Suggestion:

                "Mango", "Pineapple", "Banana"};

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 71:

> 69:         JComboBox<String> comboBox = new JComboBox<String>(fruits);
> 70:         JPanel fruitPanel = new JPanel(new GridLayout(1, 2));
> 71:         JLabel fruitLabel = new JLabel("Fruits : ", JLabel.CENTER);

Suggestion:

        JLabel fruitLabel = new JLabel("Fruits:", JLabel.CENTER);

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 75:

> 73:         fruitPanel.add(fruitLabel);
> 74:         fruitPanel.add(comboBox);
> 75:         comboBox.getAccessibleContext().setAccessibleName("Fruit jCombobox");

Suggestion:

        comboBox.getAccessibleContext().setAccessibleName("Fruit Combo box");

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 81:

> 79:         PassFailJFrame.positionTestWindow(frame,
> 80:                 PassFailJFrame.Position.HORIZONTAL);
> 81:         frame.setLocationRelativeTo(null);

Suggestion:


It's not needed, the location of the frame is set explicitly by the above call to `PassFailJFrame.positionTestWindow`.

test/jdk/javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java line 1:

> 1: /*

You should update the copyright year.

I wonder if it makes sense to resolve warnings about raw classes.

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

PR Review: https://git.openjdk.org/jdk/pull/14497#pullrequestreview-1722830503
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388181016
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388182328
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388201084
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388185906
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388191437
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388193414
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388193775
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388190556
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388195249
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388188204
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388197459
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388204973

From aivanov at openjdk.org  Thu Nov  9 17:43:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Nov 2023 17:43:10 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v8]
In-Reply-To: <WFqVTRh4NA68x17XnSDb-ZiasW2nRmsI8zV8O2Oph4Y=.149c6602-f459-471d-86b8-4b30f9e4c77c@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <71Kog6sDk_17WiI_9AU1y1zKnFW53V6nupE-bUFbMl8=.c259ed45-06cf-4c9d-8242-0a9fe9a8e333@github.com>
 <v3cC-Xir-wco0UHI_vkkxrrbEIRZwkoCGyiSBsXTpwE=.534088a8-7c80-444f-9c38-a9a199fa1eaa@github.com>
 <C0Vpeyf7fCuwbf2zqcK6_sfWHXvUkXdVgGvf1OENRoI=.de419e02-090b-4b19-ad31-3bebc6324e10@github.com>
 <Uu6LNFV-uxixqF9O_HFOirEW6aBWPqYUm8ABf2cBaKU=.39c3b79a-fa74-4699-b24c-5a0aa91ce3a7@github.com>
 <WFqVTRh4NA68x17XnSDb-ZiasW2nRmsI8zV8O2Oph4Y=.149c6602-f459-471d-86b8-4b30f9e4c77c@github.com>
Message-ID: <Wu22bvOWUtY2ECPuQtaJPYQcmwv_dapKIKdnoMJzpgA=.ee5a5274-a053-4182-91e2-ba4efc1d4bda@github.com>

On Thu, 9 Nov 2023 04:36:08 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Observed a test failure (regression) while running the CI jobs with the fix.

The failed test is `javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java`. It fails with `NullPointerException` because `PropertyChangeListener` in `AquaComboBoxUI` updates the accessible name of the arrow button. It does os before the accessible name is actually needed.

We should consider getting the accessible name lazily.

> Modified the test to fix the issue. Now, CI jobs are ok. Please review.

It looks fine to me.

But this change breaks backward compatibility: the failed test demonstrates it. If another application does something similar, it will throw NPE now.

You and I proved that adding `null`-checks in the listener or `updateAccessibleName` doesn't help. The only way to avoid it is to catch NPE.

This brings us to:

> Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. ?

This way gets the accessible name *lazily*: it's requested only *when needed*. Therefore you should submit another bug to address the limitation of the current approach.

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1804275339

From aivanov at openjdk.org  Thu Nov  9 17:51:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Nov 2023 17:51:09 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
Message-ID: <OC08xEcM6Cjp0pNlr4R2VavAKUicS7Te5sSEl2MPMkw=.29f8f7f8-59bd-4602-84d6-4a1d60e01575@github.com>

On Thu, 9 Nov 2023 04:39:32 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
>> 
>> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
>> 
>> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for custom renderer

> > Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. ?
> 
> This way gets the accessible name _lazily_: it's requested only _when needed_. Therefore you should submit another bug to address the limitation of the current approach.

Eventually, I've found the perfect solution: [commit 516af4c](https://github.com/openjdk/jdk/commit/516af4c62f59984f2d3c44bfb8ecae6fc2e88810) and [diff to jdk/master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:516af4c62f59984f2d3c44bfb8ecae6fc2e88810)

The `javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java` test passes in its unmodified version, which means the new version does not break the backward compatibility. Due to this, 8283214 should be added to the list of bugids in `UpdateUIRecursionTest`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1804285853

From abhiscxk at openjdk.org  Thu Nov  9 18:17:12 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 9 Nov 2023 18:17:12 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <OC08xEcM6Cjp0pNlr4R2VavAKUicS7Te5sSEl2MPMkw=.29f8f7f8-59bd-4602-84d6-4a1d60e01575@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
 <OC08xEcM6Cjp0pNlr4R2VavAKUicS7Te5sSEl2MPMkw=.29f8f7f8-59bd-4602-84d6-4a1d60e01575@github.com>
Message-ID: <alyO10ZSj70HQ8dNyc85wMsFJo3h1-5K1MRkK3pGvKE=.4e5d578d-9359-47de-b3bf-f96a0bdf91fa@github.com>

On Thu, 9 Nov 2023 17:48:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > Ideally, I'd like to make Aqua L&F classes work like Metal or Nimbus do. ?
> > 
> > 
> > This way gets the accessible name _lazily_: it's requested only _when needed_. Therefore you should submit another bug to address the limitation of the current approach.
> 
> Eventually, I've found the perfect solution: [commit 516af4c](https://github.com/openjdk/jdk/commit/516af4c62f59984f2d3c44bfb8ecae6fc2e88810) and [diff to jdk/master](https://github.com/openjdk/jdk/compare/master...aivanov-jdk:jdk:516af4c62f59984f2d3c44bfb8ecae6fc2e88810)
> 
> The `javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java` test passes in its unmodified version, which means the new version does not break the backward compatibility. Due to this, 8283214 should be added to the list of bugids in `UpdateUIRecursionTest`.

So, I need to revert the changes that is done in the current commit and just add the bug id 8283214... right?

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1804320116

From aivanov at openjdk.org  Thu Nov  9 18:17:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Nov 2023 18:17:12 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <alyO10ZSj70HQ8dNyc85wMsFJo3h1-5K1MRkK3pGvKE=.4e5d578d-9359-47de-b3bf-f96a0bdf91fa@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
 <OC08xEcM6Cjp0pNlr4R2VavAKUicS7Te5sSEl2MPMkw=.29f8f7f8-59bd-4602-84d6-4a1d60e01575@github.com>
 <alyO10ZSj70HQ8dNyc85wMsFJo3h1-5K1MRkK3pGvKE=.4e5d578d-9359-47de-b3bf-f96a0bdf91fa@github.com>
Message-ID: <82cbjL-d_YExr7yvdWqt4NHcxRoTWz85RHxofLuSAmU=.177d3276-bd46-4c41-805f-66c0d308314d@github.com>

On Thu, 9 Nov 2023 18:12:44 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> So, I need to revert the changes that is done in the current commit and just add the bug id 8283214... right?

Yes, that's right.

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1804323444

From abhiscxk at openjdk.org  Thu Nov  9 18:33:09 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 9 Nov 2023 18:33:09 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <ErAFMrXRO1k79ZKj5a9WsTiq4K2sF3UJD-7W8-75eRc=.ad08e29b-46a6-49f4-bf41-6e21cbcc00ae@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
 <ErAFMrXRO1k79ZKj5a9WsTiq4K2sF3UJD-7W8-75eRc=.ad08e29b-46a6-49f4-bf41-6e21cbcc00ae@github.com>
Message-ID: <MFERvAwx7J5PB2CvhmcEsDZo8MeCvUdeE4x-Bejykow=.c60fa756-a576-4477-b971-4d0bc0ed1bec@github.com>

On Thu, 9 Nov 2023 15:50:20 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I wonder if it makes sense to resolve warnings about raw classes.

I didn't get this. Which warnings need to be resolved?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388415539

From aivanov at openjdk.org  Thu Nov  9 18:33:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Nov 2023 18:33:10 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <MFERvAwx7J5PB2CvhmcEsDZo8MeCvUdeE4x-Bejykow=.c60fa756-a576-4477-b971-4d0bc0ed1bec@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
 <ErAFMrXRO1k79ZKj5a9WsTiq4K2sF3UJD-7W8-75eRc=.ad08e29b-46a6-49f4-bf41-6e21cbcc00ae@github.com>
 <MFERvAwx7J5PB2CvhmcEsDZo8MeCvUdeE4x-Bejykow=.c60fa756-a576-4477-b971-4d0bc0ed1bec@github.com>
Message-ID: <RdyF6AF6mhfgrlMciNxf9R8wszjcJFOOuJFIgSLC1TY=.28803d1b-326b-4d07-91ce-928be116d312@github.com>

On Thu, 9 Nov 2023 18:21:02 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > I wonder if it makes sense to resolve warnings about raw classes.
> 
> I didn't get this. Which warnings need to be resolved?


test/jdk/javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java:61: warning: [unchecked] unchecked call to JComboBox(E[]) as a member of the raw type JComboBox
        combo = new JComboBox(listData);
                ^
  where E is a type-variable:
    E extends Object declared in class JComboBox
test/jdk/javax/swing/JComboBox/6567433/UpdateUIRecursionTest.java:62: warning: [unchecked] unchecked call to setRenderer(ListCellRenderer<? super E>) as a member of the raw type JComboBox
        combo.setRenderer(this);
                         ^
  where E is a type-variable:
    E extends Object declared in class JComboBox
2 warnings


However, now the changes will be limited to adding a new bugid. As such, let's leave the file intact.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388427451

From abhiscxk at openjdk.org  Thu Nov  9 18:42:24 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 9 Nov 2023 18:42:24 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v10]
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <8Wboo4mx6VVjIuzsHx6ZgJ92nC-ZE2ks4QZ7Or70uXA=.77bbc4c9-15fb-42d9-a40a-a7f3307081b9@github.com>

> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
> 
> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
> 
> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
> 
> CI link is posted in JBS.

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

  Extend Accessible class to return accessible name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14497/files
  - new: https://git.openjdk.org/jdk/pull/14497/files/3191a277..e7dca03d

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

  Stats: 77 lines in 4 files changed: 29 ins; 34 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14497.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14497/head:pull/14497

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

From abhiscxk at openjdk.org  Thu Nov  9 18:42:26 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 9 Nov 2023 18:42:26 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v9]
In-Reply-To: <ErAFMrXRO1k79ZKj5a9WsTiq4K2sF3UJD-7W8-75eRc=.ad08e29b-46a6-49f4-bf41-6e21cbcc00ae@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <fTDtTyaiLtDQRmN0o8A4i1steBbPk6xw0TJ8XFqVupM=.a0fb299d-ed8f-4ae6-9e77-ad084ff861d1@github.com>
 <ErAFMrXRO1k79ZKj5a9WsTiq4K2sF3UJD-7W8-75eRc=.ad08e29b-46a6-49f4-bf41-6e21cbcc00ae@github.com>
Message-ID: <O3jxIljldeEJRYTMA8jPqMK4ZsonAiSHxpQcYeHrZBw=.f30cbae8-fb1d-4041-a96c-3c809c8e9ac8@github.com>

On Thu, 9 Nov 2023 15:33:57 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix for custom renderer
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 201:
> 
>> 199:     }
>> 200: 
>> 201:     final Component getRendererComponent() {
> 
> Suggestion:
> 
>     private Component getRendererComponent() {
> 
> 
> I wanted to use this method in `AquaComboBoxUI` but eventually I added `updateAccessibleName` instead, thus this method can be made `private`.

Updated.

> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxUI.java line 143:
> 
>> 141:             public void itemStateChanged(final ItemEvent e) {
>> 142: 
>> 143:                 if (e.getStateChange() != ItemEvent.SELECTED) return;
> 
> Suggestion:
> 
>             public void itemStateChanged(final ItemEvent e) {
>                 if (e.getStateChange() != ItemEvent.SELECTED) return;
> 
> The blank line at the start of the method isn't necessary, is it?

Removed.

> test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 81:
> 
>> 79:         PassFailJFrame.positionTestWindow(frame,
>> 80:                 PassFailJFrame.Position.HORIZONTAL);
>> 81:         frame.setLocationRelativeTo(null);
> 
> Suggestion:
> 
> 
> It's not needed, the location of the frame is set explicitly by the above call to `PassFailJFrame.positionTestWindow`.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388437524
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388438449
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388439180

From aivanov at openjdk.org  Thu Nov  9 19:19:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Nov 2023 19:19:09 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v10]
In-Reply-To: <8Wboo4mx6VVjIuzsHx6ZgJ92nC-ZE2ks4QZ7Or70uXA=.77bbc4c9-15fb-42d9-a40a-a7f3307081b9@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <8Wboo4mx6VVjIuzsHx6ZgJ92nC-ZE2ks4QZ7Or70uXA=.77bbc4c9-15fb-42d9-a40a-a7f3307081b9@github.com>
Message-ID: <_zlmXDUExPG--S64T4uzyvSTTZ0QrCEjffmAVP9tjJ0=.5f24087b-7671-403f-8d94-a75a9411fce0@github.com>

On Thu, 9 Nov 2023 18:42:24 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
>> 
>> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
>> 
>> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Extend Accessible class to return accessible name

test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 33:

> 31:  *          screen magnifier a11y tool
> 32:  * @run main/manual TestJComboBoxScreenMagnifier
> 33:  */

Could you please move the jtreg tags below the imports, above the class declaration? This way, they're easier to see in an IDE. Not required though, some people still prefer the tags above the imports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388479097

From honkar at openjdk.org  Thu Nov  9 19:31:05 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 9 Nov 2023 19:31:05 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure coding
 warning
Message-ID: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>

With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:

"WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."

which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).

While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.

The fix for JDK-8318854 involves:

- implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.

- Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.

- Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m


**PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

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

Commit messages:
 - added new env var for AWT delegate override
 - single env var change
 - env var changes
 - env var AWT_OVERRIDE_DELEGATE, null check for shared delegate
 - added applicationSupportsSecureRestorableState

Changes: https://git.openjdk.org/jdk/pull/16569/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16569&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318854
  Stats: 41 lines in 4 files changed: 26 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/16569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16569/head:pull/16569

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

From honkar at openjdk.org  Thu Nov  9 19:31:06 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 9 Nov 2023 19:31:06 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning
In-Reply-To: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
Message-ID: <-Rszq04CMIvTkEyD-xyHX9kn2_jb_lfZUbG4hzYbnXc=.8e19c594-6700-4f59-acde-bba0e8ef9b77@github.com>

On Wed, 8 Nov 2023 19:49:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> 
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

@prrace and @kevinrushforth  Please review the changes and the PR description.

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

PR Comment: https://git.openjdk.org/jdk/pull/16569#issuecomment-1802557359

From kcr at openjdk.org  Thu Nov  9 20:18:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Thu, 9 Nov 2023 20:18:58 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning
In-Reply-To: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
Message-ID: <jQPAlaPmxCPSXdy6WwfsI5cyoSNWQiqe2hsNaa6gv90=.b8c19944-9469-401f-8ce1-ebbd20b99754@github.com>

On Wed, 8 Nov 2023 19:49:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> 
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

The code changes look good. So does my testing.

I tested all four combinations of:

(JDK 22 with & without the fix in this PR) X (JavaFX 22 with & without the fix in PR [jfx#1280](https://github.com/openjdk/jfx/pull/1280))

I ran the following tests with each of the above four combinations on macOS 13 and macOS 14:

* Pure Swing app -- AWT toolkit creates NSApplication (FX toolkit not started)
* JFXPanel app -- AWT toolkit creates NSApplication
* Pure JavaFX app --FX toolkit creates NSApplication (AWT toolkit not started)
* SwingNode app -- FX toolkit creates NSApplication

Everything works as expected.

For the macOS 14 specific problems:

* The secure warning is gone for Swing apps (the first two test apps) when running a JDK 22 with this patch, regardless of whether or not FX has the fix
* The secure warning is gone for JavaFX apps (the last two test apps) when running a JavaFX 22 with the patch for[jfx#1280](https://github.com/openjdk/jfx/pull/1280), regardless of whether or not the JDK has the fix
* The NSMenu assertion error reported in [JDK-8318129](https://bugs.openjdk.org/browse/JDK-8318129) is gone when running either the patched JDK or the patched FX (or both)

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

Marked as reviewed by kcr (Author).

PR Review: https://git.openjdk.org/jdk/pull/16569#pullrequestreview-1723423580

From prr at openjdk.org  Thu Nov  9 20:27:57 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 9 Nov 2023 20:27:57 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning
In-Reply-To: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
Message-ID: <03S2whf3wiuLd69f7HhBf2lLbq23mTwa1jrKjeUSlY0=.238b6b1d-4971-447b-b146-8d9cfb2c8fcf@github.com>

On Wed, 8 Nov 2023 19:49:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> 
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 534:

> 532: 
> 533:     ApplicationDelegate *delegate = [ApplicationDelegate sharedDelegate];
> 534:     if ([ApplicationDelegate sharedDelegate] != nil) {

more logical here to check the local variable you just defined.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1388545763

From aivanov at openjdk.org  Thu Nov  9 20:34:02 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 9 Nov 2023 20:34:02 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <Z5yQmEntZLhlD3-7rgirgUfahPKCOrttUuFLQZpzNdg=.4d9a620c-2bea-48c0-8d87-fded4501ae94@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
 <Z5yQmEntZLhlD3-7rgirgUfahPKCOrttUuFLQZpzNdg=.4d9a620c-2bea-48c0-8d87-fded4501ae94@github.com>
Message-ID: <XiUdbKADayLux91lWh3v1acLQa9itiXFdU0qX0oKMZo=.1dd3985d-02e1-44da-bdca-eba0727f9007@github.com>

On Wed, 8 Nov 2023 05:06:14 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Although there seems to be no difference in rendering the scrollbars with and without these getXXX methods as can be seen here (top one without, bottom one with the methods),

I guess it's expected because `LayoutManager` usually tries to satisfy the preferred size. In this case, each scroll bar gets its preferred size.

As soon as you start resizing, the differences become apparent: sizing behaviour is different? because after you remove the overridden `getMinimumSize` and `getMaximumSize` methods, the minimum and maximum sizes of the scroll bar change.

> I could see difference in behaviour when the frame is resized and since the premise of the fix is there should not be any difference in behaviour if these methods are removed, I agree that removing the methods as is done in this PR may not be appropriate

As soon as you start resizing, the differences become apparent: sizing behaviour is different? because after you remove the overridden `getMinimumSize` and `getMaximumSize` methods, the minimum and maximum sizes of the scroll bar changes.

> but I also think adding setXXX methods in JScrollBar class just to clarify existing spec may also not be appropriate. In this light, can we consider the previous iteration of the [spec clarification](https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=03#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java)

Why not? The previous iteration just adds an additional note to `getXXX` methods ? the problem with `setXXX` persists, the methods are inherited from `JComponent` and their specification states, ?Subsequent calls to `getMinimumSize` *will always return this value*? [the one passed to `setMinimumSize`], which does not hold.

https://github.com/openjdk/jdk/blob/a95062b39a431b4937ab6e9e73de4d2b8ea1ac49/src/java.desktop/share/classes/javax/swing/JComponent.java#L1782-L1784

I propose overriding `setMinimumSize` and `setMaximumSize` and amend their specification to align with the current implementation of `get{Min,Max}Size`. Otherwise, the contract of `set{Min,Max}Size` will still be broken, no matter how many additional warnings we add to their `get-` counterparts.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1804640197

From honkar at openjdk.org  Thu Nov  9 22:30:32 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 9 Nov 2023 22:30:32 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
Message-ID: <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> 
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

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

  local var reused

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16569/files
  - new: https://git.openjdk.org/jdk/pull/16569/files/7fee680b..5493f5f9

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

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

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

From honkar at openjdk.org  Thu Nov  9 22:30:32 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 9 Nov 2023 22:30:32 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning
In-Reply-To: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
Message-ID: <s6JCKYlvu2tri6ZVXQUzPJEd2TEq-3EwoFYc4ho20RI=.21f16659-42a8-429c-88cb-370767bc11df@github.com>

On Wed, 8 Nov 2023 19:49:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> 
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

@prrace There are other references to shared delegate within ApplicationDelegate.m in JNI calls such as here [#L820](https://github.com/openjdk/jdk/blob/a95062b39a431b4937ab6e9e73de4d2b8ea1ac49/src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m#L820). I haven't added null checks here because the references are within JNI calls and when this code is reached a shared delegate is positively installed because of the following condition -

`if ([NSApp isKindOfClass:[NSApplicationAWT class]]) shouldInstall = YES;`

Do you anticipate any circumstance that can still result in a null shared delegate in this case and recommend that null checks be added to these locations (within JNI calls) too?

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

PR Comment: https://git.openjdk.org/jdk/pull/16569#issuecomment-1804779156

From honkar at openjdk.org  Thu Nov  9 22:30:32 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 9 Nov 2023 22:30:32 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <03S2whf3wiuLd69f7HhBf2lLbq23mTwa1jrKjeUSlY0=.238b6b1d-4971-447b-b146-8d9cfb2c8fcf@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <03S2whf3wiuLd69f7HhBf2lLbq23mTwa1jrKjeUSlY0=.238b6b1d-4971-447b-b146-8d9cfb2c8fcf@github.com>
Message-ID: <4835F19QzS-t7CRMNJNtaWoCX5Wlv_qP5NFe5njtu3M=.6bf0f97c-12f2-43a2-b096-e1479cdd5295@github.com>

On Thu, 9 Nov 2023 20:25: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:
>> 
>>   local var reused
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 534:
> 
>> 532: 
>> 533:     ApplicationDelegate *delegate = [ApplicationDelegate sharedDelegate];
>> 534:     if ([ApplicationDelegate sharedDelegate] != nil) {
> 
> more logical here to check the local variable you just defined.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1388649837

From serb at openjdk.org  Fri Nov 10 03:04:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Nov 2023 03:04:59 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
Message-ID: <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>

On Thu, 9 Nov 2023 22:30:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> 
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   local var reused

src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 844:

> 842:     }
> 843: 
> 844:     if (menuBar == nil && [ApplicationDelegate sharedDelegate] != nil) {

Can you please provide details on how the delegate can be null here and there if it should be set at the startup of any awt application?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1388820090

From psadhukhan at openjdk.org  Fri Nov 10 03:16:58 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 03:16:58 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <XiUdbKADayLux91lWh3v1acLQa9itiXFdU0qX0oKMZo=.1dd3985d-02e1-44da-bdca-eba0727f9007@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
 <Z5yQmEntZLhlD3-7rgirgUfahPKCOrttUuFLQZpzNdg=.4d9a620c-2bea-48c0-8d87-fded4501ae94@github.com>
 <XiUdbKADayLux91lWh3v1acLQa9itiXFdU0qX0oKMZo=.1dd3985d-02e1-44da-bdca-eba0727f9007@github.com>
Message-ID: <xg8UeuwKBT8qVXO0G5qAzDRe_wXal48vC6r-sgl_1Jc=.be598a2b-1c8a-46aa-a411-2167129e9057@github.com>

On Thu, 9 Nov 2023 20:31:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Otherwise, the contract of `set{Min,Max}Size` will still be broken

That's what we are trying to clarify in the JSCrollBar spec that the contract specified in JComponent is not valid for this widget because of so and so reason, right?

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1805009496

From abhiscxk at openjdk.org  Fri Nov 10 04:30:33 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 04:30:33 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v11]
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <Za3QNZX8BWLSX_nn7jHp0wiPxBVJJAEn51w2G1XEV9M=.1c7ab2b1-12ac-4a60-b042-1ef50ebda1d9@github.com>

> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
> 
> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
> 
> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
> 
> CI link is posted in JBS.

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

  jtreg update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14497/files
  - new: https://git.openjdk.org/jdk/pull/14497/files/e7dca03d..6b41f668

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

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

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

From abhiscxk at openjdk.org  Fri Nov 10 04:30:33 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 04:30:33 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v10]
In-Reply-To: <_zlmXDUExPG--S64T4uzyvSTTZ0QrCEjffmAVP9tjJ0=.5f24087b-7671-403f-8d94-a75a9411fce0@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <8Wboo4mx6VVjIuzsHx6ZgJ92nC-ZE2ks4QZ7Or70uXA=.77bbc4c9-15fb-42d9-a40a-a7f3307081b9@github.com>
 <_zlmXDUExPG--S64T4uzyvSTTZ0QrCEjffmAVP9tjJ0=.5f24087b-7671-403f-8d94-a75a9411fce0@github.com>
Message-ID: <561SENUmu6-dI60-Msbc6MEhUKJ9Wl0kXDT8ba8fF1M=.afa16230-e58c-4cca-920d-0ac0f92d8008@github.com>

On Thu, 9 Nov 2023 19:16:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Extend Accessible class to return accessible name
>
> test/jdk/javax/accessibility/JComboBox/TestJComboBoxScreenMagnifier.java line 33:
> 
>> 31:  *          screen magnifier a11y tool
>> 32:  * @run main/manual TestJComboBoxScreenMagnifier
>> 33:  */
> 
> Could you please move the jtreg tags below the imports, above the class declaration? This way, they're easier to see in an IDE. Not required though, some people still prefer the tags above the imports.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1388884303

From tr at openjdk.org  Fri Nov 10 04:56:24 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 04:56:24 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v4]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <R3mMeTaEBRqlTlCdgr-VPVnE2osMT_NF4epbU9QNl_o=.3f95b42f-f810-4c75-a5cf-34c232d2ba17@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/9f6afa2a..c7a0988a

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

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

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

From tr at openjdk.org  Fri Nov 10 04:56:27 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 04:56:27 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
 <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>
Message-ID: <UKKkx0kD0E1GWp17XAVnUYq6b89ClpEOvTAf7qfz-as=.531bb930-12fe-4202-bafe-c62cca1ce297@github.com>

On Wed, 8 Nov 2023 13:33:26 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/JViewport.java line 607:
> 
>> 605: 
>> 606:     private Graphics getBackingStoreGraphics(Graphics g) {
>> 607:         if (g instanceof SunGraphics2D) {
> 
> One thing is the change is not obvious as to why it is being done.
> I think we can make the fix more telling by utilizing isPrinting check to make it prominent that the code path is for printing
> Suggestion:
> 
>        if (!SwingUtilities2.isPrinting(g)) {
> 
> Can you see if it works? And yes, you have to make the method public..

Yes, it works, can't use `SwingUtilities2.isPrinting(g)` but can check for `PrintGraphics` instance which is done in `SwingUtilities2.isPrinting(g)` .. Thank you for the input...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1388900035

From jwaters at openjdk.org  Fri Nov 10 05:53:10 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 10 Nov 2023 05:53:10 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v23]
In-Reply-To: <_0ydj45QFWlepdvKCAkQF1KwvuQoVHAY6Fc32L-Qcbk=.add732cb-3c57-453d-a3fa-e7edf754c0f4@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <_0ydj45QFWlepdvKCAkQF1KwvuQoVHAY6Fc32L-Qcbk=.add732cb-3c57-453d-a3fa-e7edf754c0f4@github.com>
Message-ID: <cuN2r6pdYCHsdyPwSJWTJzNu1zwJzoQ-84yvezzRbn4=.71928282-83e7-4a02-a3cc-f1adaa77c879@github.com>

On Sun, 5 Nov 2023 07:11:27 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Whitespace awt_Canvas.cpp

Bumping

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1805139067

From psadhukhan at openjdk.org  Fri Nov 10 06:41:59 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 06:41:59 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <UKKkx0kD0E1GWp17XAVnUYq6b89ClpEOvTAf7qfz-as=.531bb930-12fe-4202-bafe-c62cca1ce297@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
 <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>
 <UKKkx0kD0E1GWp17XAVnUYq6b89ClpEOvTAf7qfz-as=.531bb930-12fe-4202-bafe-c62cca1ce297@github.com>
Message-ID: <ykIwuk4fO45Zn8R4UVePZxj751s7PRQ272xABQ7Xxjw=.a69e8307-023c-4923-8ca8-e40538c197b0@github.com>

On Fri, 10 Nov 2023 04:53:15 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JViewport.java line 607:
>> 
>>> 605: 
>>> 606:     private Graphics getBackingStoreGraphics(Graphics g) {
>>> 607:         if (g instanceof SunGraphics2D) {
>> 
>> One thing is the change is not obvious as to why it is being done.
>> I think we can make the fix more telling by utilizing isPrinting check to make it prominent that the code path is for printing
>> Suggestion:
>> 
>>        if (!SwingUtilities2.isPrinting(g)) {
>> 
>> Can you see if it works? And yes, you have to make the method public..
>
> Yes, it works, can't use `SwingUtilities2.isPrinting(g)` but can check for `PrintGraphics` instance which is done in `SwingUtilities2.isPrinting(g)` .. Thank you for the input...

Why cant you use isPrinting?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1388977079

From tr at openjdk.org  Fri Nov 10 06:44:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 06:44:57 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <ykIwuk4fO45Zn8R4UVePZxj751s7PRQ272xABQ7Xxjw=.a69e8307-023c-4923-8ca8-e40538c197b0@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
 <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>
 <UKKkx0kD0E1GWp17XAVnUYq6b89ClpEOvTAf7qfz-as=.531bb930-12fe-4202-bafe-c62cca1ce297@github.com>
 <ykIwuk4fO45Zn8R4UVePZxj751s7PRQ272xABQ7Xxjw=.a69e8307-023c-4923-8ca8-e40538c197b0@github.com>
Message-ID: <vpIsLAimlmYOF6jZCjRy3xb7U0eRLpK8Rtd1hYQHPjs=.dd3df35c-7017-429c-8c10-b3a97c742c5b@github.com>

On Fri, 10 Nov 2023 06:39:29 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yes, it works, can't use `SwingUtilities2.isPrinting(g)` but can check for `PrintGraphics` instance which is done in `SwingUtilities2.isPrinting(g)` .. Thank you for the input...
>
> Why cant you use isPrinting?

It's not public..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1388979165

From psadhukhan at openjdk.org  Fri Nov 10 06:50:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 06:50:56 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <vpIsLAimlmYOF6jZCjRy3xb7U0eRLpK8Rtd1hYQHPjs=.dd3df35c-7017-429c-8c10-b3a97c742c5b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
 <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>
 <UKKkx0kD0E1GWp17XAVnUYq6b89ClpEOvTAf7qfz-as=.531bb930-12fe-4202-bafe-c62cca1ce297@github.com>
 <ykIwuk4fO45Zn8R4UVePZxj751s7PRQ272xABQ7Xxjw=.a69e8307-023c-4923-8ca8-e40538c197b0@github.com>
 <vpIsLAimlmYOF6jZCjRy3xb7U0eRLpK8Rtd1hYQHPjs=.dd3df35c-7017-429c-8c10-b3a97c742c5b@github.com>
Message-ID: <xxOlVtf_Xj81sXpcfqo87IjCe4FiXolc5DA4d9gytNA=.9aa123ce-3b75-4524-a354-47b310bcab0d@github.com>

On Fri, 10 Nov 2023 06:41:59 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Why cant you use isPrinting?
>
> It's not public..

> And yes, you have to make the method public..

Thats what I told already..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1388981671

From tr at openjdk.org  Fri Nov 10 06:50:58 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 06:50:58 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <xxOlVtf_Xj81sXpcfqo87IjCe4FiXolc5DA4d9gytNA=.9aa123ce-3b75-4524-a354-47b310bcab0d@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
 <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>
 <UKKkx0kD0E1GWp17XAVnUYq6b89ClpEOvTAf7qfz-as=.531bb930-12fe-4202-bafe-c62cca1ce297@github.com>
 <ykIwuk4fO45Zn8R4UVePZxj751s7PRQ272xABQ7Xxjw=.a69e8307-023c-4923-8ca8-e40538c197b0@github.com>
 <vpIsLAimlmYOF6jZCjRy3xb7U0eRLpK8Rtd1hYQHPjs=.dd3df35c-7017-429c-8c10-b3a97c742c5b@github.com>
 <xxOlVtf_Xj81sXpcfqo87IjCe4FiXolc5DA4d9gytNA=.9aa123ce-3b75-4524-a354-47b310bcab0d@github.com>
Message-ID: <95P-TlyQfBAkyy6URQX-Y-cchT2qYPPvZGaFcH2Owbg=.4fb3f1c2-dbe1-47d9-800c-fef0b71c6067@github.com>

On Fri, 10 Nov 2023 06:46:16 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It's not public..
>
>> And yes, you have to make the method public..
> 
> Thats what I told already..

Ok, guess I missed it..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1388984285

From serb at openjdk.org  Fri Nov 10 07:04:03 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Nov 2023 07:04:03 GMT
Subject: RFR: 8301310: The SendRawSysexMessage test may cause a JVM crash
 [v4]
In-Reply-To: <6UgLqs_DrdYFzPs2Sx0ppiI3LtbX8tSADojhK8c7eA8=.23cb1c53-811d-4ec4-a0ee-8982703d91ce@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
 <6UgLqs_DrdYFzPs2Sx0ppiI3LtbX8tSADojhK8c7eA8=.23cb1c53-811d-4ec4-a0ee-8982703d91ce@github.com>
Message-ID: <9Ww-YRLzEPSUDxKD3YD7346891w8KB1rMtX6NeHAa08=.1ec2b255-5ce3-4e59-a1e6-8b6c20b52e7c@github.com>

On Thu, 9 Nov 2023 04:13:21 GMT, Alec Su <duke at openjdk.org> wrote:

>> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
>> 
>> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
>> 
>> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
>> 
>> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
>> 
>> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.
>
> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix an error

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16477#pullrequestreview-1724147929

From tr at openjdk.org  Fri Nov 10 07:20:29 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 07:20:29 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v5]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <_xGqevJNGT9axphJai57L8Con4jCChStOMqEzBRtYu8=.9f4f67f6-674d-4f41-9961-33af8a2a3616@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/c7a0988a..a4389a02

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

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

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

From tr at openjdk.org  Fri Nov 10 07:31:19 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 07:31:19 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v4]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <LUZ0alzQIQIjwMppiucY2kmKe1tRxpB6oLVUSIXDKcw=.bc5558a3-41f2-4557-b9dc-c58ff2e232a8@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/27d6c769..9f0bfb4e

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

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

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

From psadhukhan at openjdk.org  Fri Nov 10 07:32:00 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 07:32:00 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v5]
In-Reply-To: <_xGqevJNGT9axphJai57L8Con4jCChStOMqEzBRtYu8=.9f4f67f6-674d-4f41-9961-33af8a2a3616@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <_xGqevJNGT9axphJai57L8Con4jCChStOMqEzBRtYu8=.9f4f67f6-674d-4f41-9961-33af8a2a3616@github.com>
Message-ID: <ueyf8neBcYLZUllDPpZht_jIUu8satxR2dQbK2WirQs=.c3a2827c-3e11-4e1e-98b0-b6512a7bc504@github.com>

On Fri, 10 Nov 2023 07:20:29 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

src/java.desktop/share/classes/javax/swing/JViewport.java line 52:

> 50: import sun.swing.SwingUtilities2;
> 51: import java.awt.PrintGraphics;
> 52: import java.awt.print.PrinterGraphics;

Guess these are not required..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389016671

From tr at openjdk.org  Fri Nov 10 07:32:02 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 07:32:02 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v3]
In-Reply-To: <95P-TlyQfBAkyy6URQX-Y-cchT2qYPPvZGaFcH2Owbg=.4fb3f1c2-dbe1-47d9-800c-fef0b71c6067@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <DhEwARw-2xBGQziksG5R315hrLjwkVLCxkGM1oKao34=.075292c2-3962-4e8b-9fa9-dd7bc95365f0@github.com>
 <pEQ6GuZMhbFHcLyHYCf0g_SmXCMvm7i5mHiBzvV8DwY=.79a59340-0f70-44ad-a84d-a06de84c4820@github.com>
 <UKKkx0kD0E1GWp17XAVnUYq6b89ClpEOvTAf7qfz-as=.531bb930-12fe-4202-bafe-c62cca1ce297@github.com>
 <ykIwuk4fO45Zn8R4UVePZxj751s7PRQ272xABQ7Xxjw=.a69e8307-023c-4923-8ca8-e40538c197b0@github.com>
 <vpIsLAimlmYOF6jZCjRy3xb7U0eRLpK8Rtd1hYQHPjs=.dd3df35c-7017-429c-8c10-b3a97c742c5b@github.com>
 <xxOlVtf_Xj81sXpcfqo87IjCe4FiXolc5DA4d9gytNA=.9aa123ce-3b75-4524-a354-47b310bcab0d@github.com>
 <95P-TlyQfBAkyy6URQX-Y-cchT2qYPPvZGaFcH2Owbg=.4fb3f1c2-dbe1-47d9-800c-fef0b71c6067@github.com>
Message-ID: <KZWEm4f1hO8JhKjSNIF7mx3Vtg-RXlY0-SFOMYkRIjc=.0c9b56cc-5c86-4d04-99dd-99fdae365c5f@github.com>

On Fri, 10 Nov 2023 06:47:57 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> And yes, you have to make the method public..
>> 
>> Thats what I told already..
>
> Ok, guess I missed it..

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389015259

From tr at openjdk.org  Fri Nov 10 07:33:57 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 07:33:57 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <YnWZACSGPRnTOlSHDflBQn270zpSiA5OwidRtkgrOGE=.711ab224-c8b4-4fe5-b9b2-6a0b9456222e@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <ojwV0xz46kQipAhawAopMmKsfvufPS8AMFD9qzo9OmM=.623e636a-c0ce-437b-b2ad-5f7acfc38179@github.com>
 <e5pQxqGlpwvvRQ-VdXr5faQ0ow91xk-MyOBro3Z3AZI=.ddb43998-fc7c-4549-a646-a48b3fdaff0a@github.com>
 <RLbXG8GiKdElK952MVJsRPHAlMqjc4hLLt7kdnRB5qE=.927e0b2a-2beb-4f35-bed6-f2e5fda7315a@github.com>
 <YnWZACSGPRnTOlSHDflBQn270zpSiA5OwidRtkgrOGE=.711ab224-c8b4-4fe5-b9b2-6a0b9456222e@github.com>
Message-ID: <dzwSeMC_XLDEfgaxOLFBveA1M_bxYqd_BJI39Ab4MpM=.1b08d0bc-35f6-4281-8e77-9e573d7b0771@github.com>

On Wed, 8 Nov 2023 11:18:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Ok..But why it is needed for RTL and not for LTR?
>
> My guess is for RTL the first column might not start from extreme left, as we drag it moves towards the Left corner, this might be for that, still not sure, will verify and come back on this.

You are right, its not required and couldn't find any reason why it was added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1389017910

From tr at openjdk.org  Fri Nov 10 07:41:22 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 07:41:22 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v6]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <G3YYvspq1aLk8hNh_fdO7NaCl3UyVMBB4m25i6VjkVg=.03df7a86-f402-46cc-8bdb-288c205a8091@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/a4389a02..89fce5d0

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

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

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

From psadhukhan at openjdk.org  Fri Nov 10 07:59:02 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 07:59:02 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v6]
In-Reply-To: <G3YYvspq1aLk8hNh_fdO7NaCl3UyVMBB4m25i6VjkVg=.03df7a86-f402-46cc-8bdb-288c205a8091@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <G3YYvspq1aLk8hNh_fdO7NaCl3UyVMBB4m25i6VjkVg=.03df7a86-f402-46cc-8bdb-288c205a8091@github.com>
Message-ID: <MyhEnNTPBhIfErL7_EmcrtOU8YgUyUagzfBY7UVdVMs=.f2a45aed-d053-49f6-94fc-0aaeb18c52ea@github.com>

On Fri, 10 Nov 2023 07:41:22 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 100:

> 98:             model.addColumn("Column 4");
> 99: 
> 100:             for (int row=1;row<=5;row++)

Need a {
and space needed between operator and number

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 168:

> 166:                 double yscale = imageableY/panelY;
> 167:                 double optimalScale;
> 168:                 if (xscale < yscale)

if -else need a {

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 173:

> 171:                     optimalScale = yscale;
> 172: 
> 173:                 if (optimalScale > 1)

here too

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389036249
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389036787
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389036982

From jwaters at openjdk.org  Fri Nov 10 08:59:24 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 10 Nov 2023 08:59:24 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v24]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <DFpGyeD_7fYSWxThmJoXppCoWLrN0PyLg61mnZlEx6w=.75ea3d42-56c5-4844-b4d7-8b46b1518f52@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  std::unique_ptr awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/e30d680b..7fe76d55

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=22-23

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

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

From tr at openjdk.org  Fri Nov 10 09:11:20 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 09:11:20 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v7]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <Vd6DoZerapP1qq8AgS1AI4pBcVTnZJh7ocwdBb1qoME=.af877c69-5ed7-4ce7-9374-14d19c5c45db@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/89fce5d0..cac0c620

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

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

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

From tr at openjdk.org  Fri Nov 10 09:14:25 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 09:14:25 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v8]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <qpdQ7erIWd0kMUMP220LklQENBPeeynre8W_IGZPt30=.748824d2-6a86-4ac0-885c-40414b5aa535@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/cac0c620..8111eaa8

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

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

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

From jwaters at openjdk.org  Fri Nov 10 09:36:39 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 10 Nov 2023 09:36:39 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v25]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <ckvh4D2Idzy50-VReUfstfKFEtM7msAs88zLrlpfR2o=.084baa22-d694-44cb-96f9-f684fbb7912c@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Ditto for awt_Component.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/7fe76d55..9259924e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=23-24

  Stats: 37 lines in 1 file changed: 4 ins; 16 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/15096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096

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

From psadhukhan at openjdk.org  Fri Nov 10 09:58:00 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 09:58:00 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v8]
In-Reply-To: <qpdQ7erIWd0kMUMP220LklQENBPeeynre8W_IGZPt30=.748824d2-6a86-4ac0-885c-40414b5aa535@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <qpdQ7erIWd0kMUMP220LklQENBPeeynre8W_IGZPt30=.748824d2-6a86-4ac0-885c-40414b5aa535@github.com>
Message-ID: <-wNu0wOalDZ0N0VM3cI1zpKR4ijByhlnAf93yAwjeGc=.c0d18637-0440-4386-9748-6605441bf129@github.com>

On Fri, 10 Nov 2023 09:14:25 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16552#pullrequestreview-1724436068

From jwaters at openjdk.org  Fri Nov 10 10:17:30 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 10 Nov 2023 10:17:30 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v26]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Comment awt_DnDDS.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/9259924e..b7c0002a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=24-25

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

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

From abhiscxk at openjdk.org  Fri Nov 10 11:16:09 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 11:16:09 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v8]
In-Reply-To: <qpdQ7erIWd0kMUMP220LklQENBPeeynre8W_IGZPt30=.748824d2-6a86-4ac0-885c-40414b5aa535@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <qpdQ7erIWd0kMUMP220LklQENBPeeynre8W_IGZPt30=.748824d2-6a86-4ac0-885c-40414b5aa535@github.com>
Message-ID: <5ZwfOWWRGgLUd97bgmk20ESqvqqgt0Yk3hRjZvpIz7I=.5b6648c1-cf9c-4fd2-9552-33dcd4675fef@github.com>

On Fri, 10 Nov 2023 09:14:25 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Minor findings.

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 48:

> 46:  * @library /java/awt/regtesthelpers
> 47:  * @build PassFailJFrame
> 48:  * @summary Test to check if JTable can be printed when it is

I think summary should be..
Suggestion:

 * @summary Test to check if JTable can be printed when JScrollPane added to it.

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 68:

> 66:     }
> 67: 
> 68:     public static void initialize() throws Exception{

Suggestion:

    public static void initialize() throws Exception {

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 78:

> 76:         TestTable testTable = new TestTable(true);
> 77:         frame = new JFrame("JTable Print Test");
> 78:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 6, 35);

If you want then you can use builder pattern for configuring PassFailJFrame.

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 122:

> 120:     static class PrintUtilities implements Printable {
> 121:         private Component componentToBePrinted;
> 122:         public void printComponent(Component c, String jobname) {

Blank line before this.

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 137:

> 135:             // set margins to 1/2"
> 136:             Paper p = new Paper();
> 137:             p.setImageableArea(36, 36, p.getWidth()-72, p.getHeight()-72);

Suggestion:

            p.setImageableArea(36, 36, p.getWidth() - 72, p.getHeight() - 72);

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 158:

> 156:                 Graphics2D g2d = (Graphics2D)g;
> 157:                 g2d.translate(pageFormat.getImageableX(), pageFormat.getImageableY());
> 158:                 Component c= componentToBePrinted;

Suggestion:

                Component c = componentToBePrinted;

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 163:

> 161:                 double panelX= c.getWidth();
> 162:                 double panelY= c.getHeight();
> 163:                 float imageableX = (float) pageFormat.getImageableWidth()-1;

Suggestion:

                float imageableX = (float) pageFormat.getImageableWidth() - 1;

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 164:

> 162:                 double panelY= c.getHeight();
> 163:                 float imageableX = (float) pageFormat.getImageableWidth()-1;
> 164:                 float imageableY = (float) pageFormat.getImageableHeight()-1;

Suggestion:

                float imageableY = (float) pageFormat.getImageableHeight() - 1;

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

PR Review: https://git.openjdk.org/jdk/pull/16552#pullrequestreview-1724556100
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389259387
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389260014
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389261148
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389261967
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389263199
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389263836
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389264335
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389264651

From tr at openjdk.org  Fri Nov 10 11:32:20 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 11:32:20 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v9]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <ZEl35CTRsMcX_bwv15mk1wlhX3QjmdOzuooH1w8W70M=.2de76e15-f3b8-45ff-af71-04fa7fd84fc3@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/8111eaa8..7a359074

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

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

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

From aivanov at openjdk.org  Fri Nov 10 11:35:08 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Nov 2023 11:35:08 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <1EL-g2U6_AsI1MvE_5ULbXHexjMqx-ZX4HyKwnomOxg=.41f9a0d2-27fa-45f9-9860-7f59db506587@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

> > Otherwise, the contract of `set{Min,Max}Size` will still be broken
> 
> That's what we are trying to clarify in the JScrollBar spec that the contract specified in JComponent is not valid for this widget because of so and so reason, right?

Exactly! And it is the `set-` functions that need to change.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1805569933

From tr at openjdk.org  Fri Nov 10 11:36:34 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 11:36:34 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v8]
In-Reply-To: <5ZwfOWWRGgLUd97bgmk20ESqvqqgt0Yk3hRjZvpIz7I=.5b6648c1-cf9c-4fd2-9552-33dcd4675fef@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <qpdQ7erIWd0kMUMP220LklQENBPeeynre8W_IGZPt30=.748824d2-6a86-4ac0-885c-40414b5aa535@github.com>
 <5ZwfOWWRGgLUd97bgmk20ESqvqqgt0Yk3hRjZvpIz7I=.5b6648c1-cf9c-4fd2-9552-33dcd4675fef@github.com>
Message-ID: <EhMb0h-u0YATy-BWFSKq4oszwSVk4YiPbYVvyWKWXb4=.9a843b1b-d8a4-49b8-aab6-bdc542ea1668@github.com>

On Fri, 10 Nov 2023 11:09:13 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 78:
> 
>> 76:         TestTable testTable = new TestTable(true);
>> 77:         frame = new JFrame("JTable Print Test");
>> 78:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 6, 35);
> 
> If you want then you can use builder pattern for configuring PassFailJFrame.

Not required I guess.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389283996

From tr at openjdk.org  Fri Nov 10 11:36:32 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 10 Nov 2023 11:36:32 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v10]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <iATiu76CUlranPi6oFuOknx2B-_LjQnvotw4hgQzdDU=.0e3433c6-62ca-4fe2-a879-a5d68389da3b@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/7a359074..dbcc134b

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

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

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

From abhiscxk at openjdk.org  Fri Nov 10 11:40:02 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 11:40:02 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v8]
In-Reply-To: <EhMb0h-u0YATy-BWFSKq4oszwSVk4YiPbYVvyWKWXb4=.9a843b1b-d8a4-49b8-aab6-bdc542ea1668@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <qpdQ7erIWd0kMUMP220LklQENBPeeynre8W_IGZPt30=.748824d2-6a86-4ac0-885c-40414b5aa535@github.com>
 <5ZwfOWWRGgLUd97bgmk20ESqvqqgt0Yk3hRjZvpIz7I=.5b6648c1-cf9c-4fd2-9552-33dcd4675fef@github.com>
 <EhMb0h-u0YATy-BWFSKq4oszwSVk4YiPbYVvyWKWXb4=.9a843b1b-d8a4-49b8-aab6-bdc542ea1668@github.com>
Message-ID: <Db55iTLSGyEhQMrOSVX9D88jN2DG_Fmx7Lyd6g8UasA=.7fc0abbe-2912-4e97-b3c6-c633e960327b@github.com>

On Fri, 10 Nov 2023 11:33:09 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 78:
>> 
>>> 76:         TestTable testTable = new TestTable(true);
>>> 77:         frame = new JFrame("JTable Print Test");
>>> 78:         passFailJFrame = new PassFailJFrame("Test Instructions", INSTRUCTIONS, 5L, 6, 35);
>> 
>> If you want then you can use builder pattern for configuring PassFailJFrame.
>
> Not required I guess.

Not required really, just a suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1389287905

From abhiscxk at openjdk.org  Fri Nov 10 11:44:03 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 11:44:03 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v10]
In-Reply-To: <iATiu76CUlranPi6oFuOknx2B-_LjQnvotw4hgQzdDU=.0e3433c6-62ca-4fe2-a879-a5d68389da3b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <iATiu76CUlranPi6oFuOknx2B-_LjQnvotw4hgQzdDU=.0e3433c6-62ca-4fe2-a879-a5d68389da3b@github.com>
Message-ID: <HssSDOgquBhxiFbVs3PxOLf2X2or3yKzt8Jsetw8t3g=.2d44b58e-ba9f-482f-a4e5-f38558aba9f1@github.com>

On Fri, 10 Nov 2023 11:36:32 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Marked as reviewed by abhiscxk (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16552#pullrequestreview-1724606677

From psadhukhan at openjdk.org  Fri Nov 10 11:58:01 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 11:58:01 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <1EL-g2U6_AsI1MvE_5ULbXHexjMqx-ZX4HyKwnomOxg=.41f9a0d2-27fa-45f9-9860-7f59db506587@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
 <1EL-g2U6_AsI1MvE_5ULbXHexjMqx-ZX4HyKwnomOxg=.41f9a0d2-27fa-45f9-9860-7f59db506587@github.com>
Message-ID: <M6--qWtoHYl6UdR-JaOs91WIWb1A8UZWJFtjKdPSYOk=.f13bdd0c-23e3-4838-9fc1-0b1446b0316e@github.com>

On Fri, 10 Nov 2023 11:32:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > Otherwise, the contract of `set{Min,Max}Size` will still be broken
> > 
> > 
> > That's what we are trying to clarify in the JScrollBar spec that the contract specified in JComponent is not valid for this widget because of so and so reason, right?
> 
> Exactly! And it is the `set-` functions that need to change.

So, you want to just add new set methods to this class just to add some clarification without any implementation change?
OK with me but need to wait for @prrace also to provide his inputs too...If he also is ok to add the spec clarification in to be newly added set methods, instead of the existing get methods which he was ok with at start, I can do the needful..

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1805606342

From aivanov at openjdk.org  Fri Nov 10 12:06:11 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Nov 2023 12:06:11 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v11]
In-Reply-To: <Za3QNZX8BWLSX_nn7jHp0wiPxBVJJAEn51w2G1XEV9M=.1c7ab2b1-12ac-4a60-b042-1ef50ebda1d9@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <Za3QNZX8BWLSX_nn7jHp0wiPxBVJJAEn51w2G1XEV9M=.1c7ab2b1-12ac-4a60-b042-1ef50ebda1d9@github.com>
Message-ID: <xNjARCITKc5-3siRoPGoiKjcOiNeKtsRH2F2LD05eis=.feb2e7ee-8adc-40b3-93bc-c8fb147eb6ff@github.com>

On Fri, 10 Nov 2023 04:30:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
>> 
>> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
>> 
>> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   jtreg update

Looks good to me.

Someone else should also approve it.

src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 276:

> 274:                     name = c.getAccessibleContext().getAccessibleName();
> 275:                 }
> 276:             }

For the button, super usually returns `""` (empty string) which is the default caption of the button. This code preserves the common behaviour of `getAccessibleName`, in particular it returns `accessibleName` field if it's set.

Since the arrow button is an internal component, we may drop calling `super`. However, I'm unsure about it.

The two `if` statements could be combined into one:


            if ((name == null || name.isEmpty())
                && (!comboBox.isEditable() && comboBox.getSelectedItem() != null)) {

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14497#pullrequestreview-1724628970
PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1389305637

From kcr at openjdk.org  Fri Nov 10 14:06:58 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Nov 2023 14:06:58 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
Message-ID: <qNGzpkcaKLQvz2atEnr8-sfAYP6OlWvRJJTa5pnV23o=.c9a7ae90-58f6-4a6c-842c-b65afddd0ee5@github.com>

On Thu, 9 Nov 2023 22:30:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> 
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   local var reused

Marked as reviewed by kcr (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/16569#pullrequestreview-1724855400

From kcr at openjdk.org  Fri Nov 10 14:10:00 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 10 Nov 2023 14:10:00 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
Message-ID: <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Fri, 10 Nov 2023 03:02:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   local var reused
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 844:
> 
>> 842:     }
>> 843: 
>> 844:     if (menuBar == nil && [ApplicationDelegate sharedDelegate] != nil) {
> 
> Can you please provide details on how the delegate can be null here and there if it should be set at the startup of any awt application?

It can be null if the NSApplication was created by code outside of AWT. Specifically, in the case of an FX or SWT toolkit, but in theory a native application using JAWT could do this.

In practice, since we haven't even seen a crash as a result of this, I doubt that this code is ever called if AWT isn't running the event loop and hasn't installed their delegate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1389448038

From psadhukhan at openjdk.org  Fri Nov 10 14:21:05 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 10 Nov 2023 14:21:05 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals
Message-ID: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>

CSSBackgroundImage.equals() is implemented

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

Commit messages:
 - 8318113: CSS.BackgroundImage doesn't implement equals
 - 8318113: CSS.BackgroundImage doesn't implement equals

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

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

From aivanov at openjdk.org  Fri Nov 10 15:26:58 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 10 Nov 2023 15:26:58 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <2kHyWJktEA4BAaBj8Mnhf7zJk0qASek6HvEs4dBeeRo=.469f39b6-ada0-4739-a253-d9fcce05b89f@github.com>

On Fri, 10 Nov 2023 13:50:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSSBackgroundImage.equals() is implemented

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16613#pullrequestreview-1725016640

From abhiscxk at openjdk.org  Fri Nov 10 18:20:27 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 18:20:27 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v12]
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <190JP0hYXltMoY_EBQg8hsitiUvtvQIj5wM2Zy8C6OY=.75e827bb-4a3d-4d82-ba8d-09ff26e852d8@github.com>

> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
> 
> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
> 
> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
> 
> CI link is posted in JBS.

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

  Condition combined

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14497/files
  - new: https://git.openjdk.org/jdk/pull/14497/files/6b41f668..b8e3dea8

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

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

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

From abhiscxk at openjdk.org  Fri Nov 10 18:20:28 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 18:20:28 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v11]
In-Reply-To: <xNjARCITKc5-3siRoPGoiKjcOiNeKtsRH2F2LD05eis=.feb2e7ee-8adc-40b3-93bc-c8fb147eb6ff@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <Za3QNZX8BWLSX_nn7jHp0wiPxBVJJAEn51w2G1XEV9M=.1c7ab2b1-12ac-4a60-b042-1ef50ebda1d9@github.com>
 <xNjARCITKc5-3siRoPGoiKjcOiNeKtsRH2F2LD05eis=.feb2e7ee-8adc-40b3-93bc-c8fb147eb6ff@github.com>
Message-ID: <zGbJE9iP32pq9cHGq-YKVMZNTxz1RohVC4w0HGgWQb8=.a43d96f5-12fc-4434-bfa7-c66d0964e363@github.com>

On Fri, 10 Nov 2023 11:58:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   jtreg update
>
> src/java.desktop/macosx/classes/com/apple/laf/AquaComboBoxButton.java line 276:
> 
>> 274:                     name = c.getAccessibleContext().getAccessibleName();
>> 275:                 }
>> 276:             }
> 
> For the button, super usually returns `""` (empty string) which is the default caption of the button. This code preserves the common behaviour of `getAccessibleName`, in particular it returns `accessibleName` field if it's set.
> 
> Since the arrow button is an internal component, we may drop calling `super`. However, I'm unsure about it.
> 
> The two `if` statements could be combined into one:
> 
> 
>             if ((name == null || name.isEmpty())
>                 && (!comboBox.isEditable() && comboBox.getSelectedItem() != null)) {

Conditions combined.

> Since the arrow button is an internal component, we may drop calling super. However, I'm unsure about it.

I think we can keep this as it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14497#discussion_r1389729338

From abhiscxk at openjdk.org  Fri Nov 10 18:23:15 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 10 Nov 2023 18:23:15 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v8]
In-Reply-To: <H79UvaYMpdqMtafxfTOtJHPaOKAKcBMta_YRlXKHkAE=.705e00a4-2131-44a5-bfa3-78c07f9505b2@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <71Kog6sDk_17WiI_9AU1y1zKnFW53V6nupE-bUFbMl8=.c259ed45-06cf-4c9d-8242-0a9fe9a8e333@github.com>
 <H79UvaYMpdqMtafxfTOtJHPaOKAKcBMta_YRlXKHkAE=.705e00a4-2131-44a5-bfa3-78c07f9505b2@github.com>
Message-ID: <E1rUKQN0fQw5GBtpp2jRE9xbYkeHBshBXpDq9kfilzE=.0c88d797-5b18-4168-ba00-15305ba3a975@github.com>

On Thu, 12 Oct 2023 15:33:49 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - AccessibleName set in Listener
>>  - Master
>>  - Revert BasicComboBoxUI fix and update review comment
>>  - bugid removed in comments
>>  - Add condition to check JLabel instance
>>  - set accessiblename to displayed text in JComboBox
>>  - Merge
>>  - Explicit frame dispose remove
>>  - merge
>>  - Review comment update
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/7ec22be6...1a48076b
>
> Looks good now.

@azuev-java As suggested by @aivanov-jdk  the current fix ensures that screen magnifier works well with the default renderer as well as custom renderer. Ci jobs are green with this fix.

Can you please re-review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/14497#issuecomment-1806204005

From serb at openjdk.org  Fri Nov 10 21:10:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Nov 2023 21:10:58 GMT
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
In-Reply-To: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
References: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
Message-ID: <2pZpvSAjuzxSP_G2plr1-JRDUlliTHg0gQAQlfaedkA=.8d76ccd3-2935-4f2c-bba1-a4b62492e103@github.com>

On Tue, 7 Nov 2023 19:18:28 GMT, Jan Trukenm?ller <duke at openjdk.org> wrote:

> The MIDI file parser misinterprets events without status byte when they appear directly after a Meta of SysEx event.
> 
> For my bugfix I had to decide between two possible solutions:
> - Strict solution: Throw an InvalidMidiDataException
> - Tolerant solution: Use the status of the last channel event as running status
> 
> I used the tolerant solution.
> I will send an email to the list client-libs-dev with my reasons.

test/jdk/javax/sound/midi/File/SMFInterruptedRunningStatus.java line 70:

> 68:         }
> 69:     }
> 70: 

please split the long lines above to have 80 chars per line.

The code below for "SMF_1"/etc are fine as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16546#discussion_r1389923729

From serb at openjdk.org  Fri Nov 10 21:12:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Nov 2023 21:12:58 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <BwvctAcFS0lydNNJwqQAy5E17XlhEVRtunISD8io25M=.93a56b10-2bcc-41d1-bbcc-27f46a0282ed@github.com>

On Thu, 2 Nov 2023 04:13:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 79:

> 77: 
> 78:                 BufferedImage borderPaintedImg =
> 79:                         robot.createScreenCapture(new Rectangle(pt.x, pt.y,

I think the test can be simplified by rendering the progress bar into the buffered image directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1389925080

From serb at openjdk.org  Fri Nov 10 21:14:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Nov 2023 21:14:57 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <AutD3_uBAZqA_rkTbjEYMygL7YL4WIk_G-WBcEzuNmQ=.2f769f9f-4902-4ca1-af98-2ceee3bb7f8c@github.com>

On Fri, 10 Nov 2023 13:50:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSSBackgroundImage.equals() is implemented

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2971:

> 2969:         @Override
> 2970:         public int hashCode() {
> 2971:             return (this.svalue != null) ? this.svalue.hashCode() : 0;

This change look fine, but this line can be simplified by the Objects.hashCode();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16613#discussion_r1389926424

From serb at openjdk.org  Fri Nov 10 21:28:57 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 10 Nov 2023 21:28:57 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
Message-ID: <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>

On Fri, 10 Nov 2023 14:07:23 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m line 844:
>> 
>>> 842:     }
>>> 843: 
>>> 844:     if (menuBar == nil && [ApplicationDelegate sharedDelegate] != nil) {
>> 
>> Can you please provide details on how the delegate can be null here and there if it should be set at the startup of any awt application?
>
> It can be null if the NSApplication was created by code outside of AWT. Specifically, in the case of an FX or SWT toolkit, but in theory a native application using JAWT could do this.
> 
> In practice, since we haven't even seen a crash as a result of this, I doubt that this code is ever called if AWT isn't running the event loop and hasn't installed their delegate.

To access any native code in AWT the app should initially init the LWCToolkit which sets that application delegate if it is not set already. Do we know how the FX can bypass that initialization?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1389938434

From prr at openjdk.org  Fri Nov 10 22:33:57 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 10 Nov 2023 22:33:57 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
Message-ID: <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>

On Fri, 10 Nov 2023 21:26:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It can be null if the NSApplication was created by code outside of AWT. Specifically, in the case of an FX or SWT toolkit, but in theory a native application using JAWT could do this.
>> 
>> In practice, since we haven't even seen a crash as a result of this, I doubt that this code is ever called if AWT isn't running the event loop and hasn't installed their delegate.
>
> To access any native code in AWT the app should initially init the LWCToolkit which sets that application delegate if it is not set already. Do we know how the FX can bypass that initialization?

In the case when AWT is embedded AWT does NOT start an  NSApplication and does not own it.
AWT overwriting FX's delegate, or any one else's is just plain wrong.

We can turn around what you said
"To access any native code in JavafX, the app should initialise GlassToolkit which sets its delegate, if not already set".

But you can't have both of these.

Meaning AWT isn't special here. It has to play by the same rules.

The toolkit that starts the NSApplication is the one that should be setting the delegate.
If you are embedded in someone else's application, it seems most logical that you defer to their application
and if this means some things aren't possible,  so be it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1389984998

From prr at openjdk.org  Fri Nov 10 22:41:57 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 10 Nov 2023 22:41:57 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
Message-ID: <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>

On Fri, 10 Nov 2023 22:31:34 GMT, Phil Race <prr at openjdk.org> wrote:

>> To access any native code in AWT the app should initially init the LWCToolkit which sets that application delegate if it is not set already. Do we know how the FX can bypass that initialization?
>
> In the case when AWT is embedded AWT does NOT start an  NSApplication and does not own it.
> AWT overwriting FX's delegate, or any one else's is just plain wrong.
> 
> We can turn around what you said
> "To access any native code in JavafX, the app should initialise GlassToolkit which sets its delegate, if not already set".
> 
> But you can't have both of these.
> 
> Meaning AWT isn't special here. It has to play by the same rules.
> 
> The toolkit that starts the NSApplication is the one that should be setting the delegate.
> If you are embedded in someone else's application, it seems most logical that you defer to their application
> and if this means some things aren't possible,  so be it.

> Can you please provide details on how the delegate can be null here and there if it should be set at the startup of any awt application?

I commented on these in https://bugs.openjdk.org/browse/JDK-8319255 which is now closed as a dup.
There I wrote (in part) 
#######

I am not sure if these are all cases that can provably be in un-reachable code in the "nil" case, which
means some embedded case. But if we ever do reach them, it seems we'd crash the app.
And if we need to make the delegate "nil" in the non-subclassed NSApplication case (ie like FX)
then we are more likely to cause a crash.

[list of places elided]

All these call sites need to be examined to understand that, and if necessary a test developed to
confirm it.
And even then, it might be prudent to add checks for nil.
#####

So the request was to investigate and understand if they were needed, not just add them
@honkar-jdk can comment on what she did there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1389988271

From duke at openjdk.org  Sat Nov 11 12:32:15 2023
From: duke at openjdk.org (Jan =?UTF-8?B?VHJ1a2VubcO8bGxlcg==?=)
Date: Sat, 11 Nov 2023 12:32:15 GMT
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
 [v2]
In-Reply-To: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
References: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
Message-ID: <L83q9-jn2-qpuV2Cto24B80SWaq-qB0lnzSKY_5lUcg=.453ac025-217a-42d1-b0cd-64eb55524cf6@github.com>

> The MIDI file parser misinterprets events without status byte when they appear directly after a Meta of SysEx event.
> 
> For my bugfix I had to decide between two possible solutions:
> - Strict solution: Throw an InvalidMidiDataException
> - Tolerant solution: Use the status of the last channel event as running status
> 
> I used the tolerant solution.
> I will send an email to the list client-libs-dev with my reasons.

Jan Trukenm?ller has updated the pull request incrementally with one additional commit since the last revision:

  reduced line lengths

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16546/files
  - new: https://git.openjdk.org/jdk/pull/16546/files/2c23d725..d7aea29a

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

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

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

From duke at openjdk.org  Sat Nov 11 12:32:16 2023
From: duke at openjdk.org (Jan =?UTF-8?B?VHJ1a2VubcO8bGxlcg==?=)
Date: Sat, 11 Nov 2023 12:32:16 GMT
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
 [v2]
In-Reply-To: <2pZpvSAjuzxSP_G2plr1-JRDUlliTHg0gQAQlfaedkA=.8d76ccd3-2935-4f2c-bba1-a4b62492e103@github.com>
References: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
 <2pZpvSAjuzxSP_G2plr1-JRDUlliTHg0gQAQlfaedkA=.8d76ccd3-2935-4f2c-bba1-a4b62492e103@github.com>
Message-ID: <n2fR9nBFSF694U_D08qh53sd0vpW1I7j8W-YZXIpQU0=.d3e5be82-bede-41d4-9124-b31b4dd007ff@github.com>

On Fri, 10 Nov 2023 21:08:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Jan Trukenm?ller has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reduced line lengths
>
> test/jdk/javax/sound/midi/File/SMFInterruptedRunningStatus.java line 70:
> 
>> 68:         }
>> 69:     }
>> 70: 
> 
> please split the long lines above to have 80 chars per line.
> 
> The code below for "SMF_1"/etc are fine as is.

Thank you for the suggestion. I reduced the line lengths.
Also for the code below SMF_..., even if you think it was fine.
I think now it's even more readable. But I can redo this part, if you think it was better before.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16546#discussion_r1390218225

From aturbanov at openjdk.org  Mon Nov 13 08:16:03 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 13 Nov 2023 08:16:03 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v10]
In-Reply-To: <iATiu76CUlranPi6oFuOknx2B-_LjQnvotw4hgQzdDU=.0e3433c6-62ca-4fe2-a879-a5d68389da3b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
 <iATiu76CUlranPi6oFuOknx2B-_LjQnvotw4hgQzdDU=.0e3433c6-62ca-4fe2-a879-a5d68389da3b@github.com>
Message-ID: <A10bJZu4NkGQ9nv6TI02OOZMm3QKU6S4iru_MQxMlH8=.f7bbe7d9-3593-48c3-93b4-1b6bd0721ec5@github.com>

On Fri, 10 Nov 2023 11:36:32 GMT, Tejesh R <tr at openjdk.org> wrote:

>> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
>> The fix is tested in CI and doesn't cause any regression. The test is verified manually.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 146:

> 144:                 try {
> 145:                     printJob.print();
> 146:                 } catch(PrinterException pe) {

Suggestion:

                } catch (PrinterException pe) {

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 154:

> 152:         public int print(Graphics g, PageFormat pageFormat, int pageIndex) {
> 153:             if (pageIndex > 0) {
> 154:                 return(NO_SUCH_PAGE);

Suggestion:

                return NO_SUCH_PAGE;

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 181:

> 179:                 g2d.scale(optimalScale, optimalScale);
> 180:                 c.paint(g2d);
> 181:                 return(PAGE_EXISTS);

Suggestion:

                return PAGE_EXISTS;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1390733523
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1390734338
PR Review Comment: https://git.openjdk.org/jdk/pull/16552#discussion_r1390735060

From aturbanov at openjdk.org  Mon Nov 13 08:36:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 13 Nov 2023 08:36:00 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <lLqcFKjiCHpjgaBq_skQQimFzDLQbEbgYjZuxBgtGKw=.281a823c-9af4-4a1e-bb40-0f7098d72a4c@github.com>

On Thu, 2 Nov 2023 04:13:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 126:

> 124:         frame = new JFrame("Test JProgressBar Border");
> 125:         JPanel p = new JPanel(new FlowLayout());
> 126:         progressBar  = new JProgressBar();

Suggestion:

        progressBar = new JProgressBar();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1390757118

From azvegint at openjdk.org  Mon Nov 13 17:37:06 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 13 Nov 2023 17:37:06 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux with
 Wayland
Message-ID: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>

This is the fix for the regression introduced in [JDK-8280993](https://bugs.openjdk.org/browse/JDK-8280993).

That fix was to dismiss a popup if the owner loses the window focus when running in Wayland, and didn't take into account that the popup itself can be focusable.

This fix closes the popup only if the focus moves away from the calling window and the popup itself.

There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).

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

Commit messages:
 - 8319103: Popups that request focus are not shown on Linux with Wayland

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

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

From serb at openjdk.org  Mon Nov 13 19:00:59 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 13 Nov 2023 19:00:59 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux
 with Wayland
In-Reply-To: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
Message-ID: <Un9Fq9AUBevMZPtpNbWLh1pHMLhLBVa-tVq_ij75j1U=.b57a34d8-11f6-406a-b1cc-fd40ce35549c@github.com>

On Mon, 13 Nov 2023 17:30:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).

Can this be covered by the manual test? We have a few manual tests which asked to use both java and native apps together.

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

PR Comment: https://git.openjdk.org/jdk/pull/16636#issuecomment-1808821538

From azvegint at openjdk.org  Mon Nov 13 20:05:50 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 13 Nov 2023 20:05:50 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux
 with Wayland [v2]
In-Reply-To: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
Message-ID: <UztWycXXHdXM8-iIFZDnqOqJDnxZVJIsGZISnDEPfUA=.17d634f8-b3de-4f73-9be7-cea5ca5b6846@github.com>

> This is the fix for the regression introduced in [JDK-8280993](https://bugs.openjdk.org/browse/JDK-8280993).
> 
> That fix was to dismiss a popup if the owner loses the window focus when running in Wayland, and didn't take into account that the popup itself can be focusable.
> 
> This fix closes the popup only if the focus moves away from the calling window and the popup itself.
> 
> There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).

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

  manual test added

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16636/files
  - new: https://git.openjdk.org/jdk/pull/16636/files/0421fedc..06850c0d

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

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

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

From azvegint at openjdk.org  Mon Nov 13 20:05:52 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 13 Nov 2023 20:05:52 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux
 with Wayland
In-Reply-To: <Un9Fq9AUBevMZPtpNbWLh1pHMLhLBVa-tVq_ij75j1U=.b57a34d8-11f6-406a-b1cc-fd40ce35549c@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
 <Un9Fq9AUBevMZPtpNbWLh1pHMLhLBVa-tVq_ij75j1U=.b57a34d8-11f6-406a-b1cc-fd40ce35549c@github.com>
Message-ID: <9hYpPLAW3zjBIEvZeG8padfpDxtPZdUlirdT-CJmVqM=.162ff914-b188-42f0-96ae-ee8c40aa4d6b@github.com>

On Mon, 13 Nov 2023 18:58:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Can this be covered by the manual test? We have a few manual tests which asked to use both java and native apps together.

Sure, test added.

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

PR Comment: https://git.openjdk.org/jdk/pull/16636#issuecomment-1808958807

From serb at openjdk.org  Mon Nov 13 21:38:30 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 13 Nov 2023 21:38:30 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux
 with Wayland [v2]
In-Reply-To: <UztWycXXHdXM8-iIFZDnqOqJDnxZVJIsGZISnDEPfUA=.17d634f8-b3de-4f73-9be7-cea5ca5b6846@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
 <UztWycXXHdXM8-iIFZDnqOqJDnxZVJIsGZISnDEPfUA=.17d634f8-b3de-4f73-9be7-cea5ca5b6846@github.com>
Message-ID: <LnrTfBZTcocbOYj7h_0wkbwQEDdn5cZRkxfbmvePb1k=.05c02386-e1d5-4f3a-b716-1ebfd3a1932f@github.com>

On Mon, 13 Nov 2023 20:05:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the fix for the regression introduced in [JDK-8280993](https://bugs.openjdk.org/browse/JDK-8280993).
>> 
>> That fix was to dismiss a popup if the owner loses the window focus when running in Wayland, and didn't take into account that the popup itself can be focusable.
>> 
>> This fix closes the popup only if the focus moves away from the calling window and the popup itself.
>> 
>> There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   manual test added

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16636#pullrequestreview-1728326003

From tr at openjdk.org  Tue Nov 14 04:10:04 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 14 Nov 2023 04:10:04 GMT
Subject: RFR: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated [v11]
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <FVEpPIxsskzQEraJC64mBVnePPlzsEb3PogkrdMmBvY=.7131fc92-8e12-4963-b2e5-d181bdd2e228@github.com>

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16552/files
  - new: https://git.openjdk.org/jdk/pull/16552/files/dbcc134b..9e4540ea

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

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

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

From jwaters at openjdk.org  Tue Nov 14 05:04:41 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 14 Nov 2023 05:04:41 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v18]
In-Reply-To: <4nQLHdfuUsWY0ZjmUuIchgPhRlDcnIqugGxrfrTVmuM=.66a0d90a-a01a-437b-8f1c-6045fa38a8ff@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <6ZTpZFPGD6QeKC7-Rj8BS7sx61yDWmeeG9L7IaF5evY=.5dadbbac-4723-4d91-a44e-16ac96e188df@github.com>
 <S9dYxB8L8UZp8f9UKpruV1NE4v6nFZxNs-cvGqD7ltQ=.94e2c3c1-4652-4d01-9f82-998989983180@github.com>
 <dBlzAayj8X6rOVgOxZA2CDC1hvhRIWsXvHtZ8MYM8jo=.ca882425-d5bb-4e34-8eb6-2263ef39be36@github.com>
 <4nQLHdfuUsWY0ZjmUuIchgPhRlDcnIqugGxrfrTVmuM=.66a0d90a-a01a-437b-8f1c-6045fa38a8ff@github.com>
Message-ID: <VEJoiCqaYLit00xb7nWRwMyiM21yGdzWIUZKxP0vloo=.5679e008-4579-48b6-aeff-477da5ec44fb@github.com>

On Mon, 6 Nov 2023 20:06:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace By the way, how outdated is the comment that awt.dll should not rely on msvcp.dll? As far as I can tell we now always distribute msvcp.dll in the JDK, and it would help a lot if I could use the C++ Standard Library for this. Or could I statically link the CRT into awt.dll instead, if awt.dll really should not rely on msvcp.dll?
>
>> By the way, how outdated is the comment that awt.dll should not rely on msvcp.dll? As far as I can tell we now always distribute msvcp.dll in the JDK, and it would help a lot if I could use the C++ Standard Library for this
> 
> Do we ? I'm not sure why that is. We've previously tried hard to avoid that.
> Eg https://hg.openjdk.org/jdk9/jdk9/rev/f3c96aea372d
> 
> We should still stay away from it.
> 
> But it doesn't matter because the changes you are making aren't going in the right direction.
> The root of the compiler complaints is the gotos isn't it ?
> So the code needs to be changed to not use gotos. I guess you do that but not in a way I'd endorse
> But there are hundreds of those. I guess only a few trigger the warnings ?
> So your awt_Canvas example should end up looking something like this
> WARNING: I just edited in place, haven't built it, haven't tested it, it is to show what the code should look like
> 
> 
> 
> void AwtCanvas::_SetEraseBackground(void *param)
> {
>     JNIEnv *env = (JNIEnv *)JNU_GetEnv(jvm, JNI_VERSION_1_2);
>                     
>     SetEraseBackgroundStruct *sebs = (SetEraseBackgroundStruct *)param;
>     jobject canvas = sebs->canvas;
>                     
>     if (canvas == NULL) {
>         env->ExceptionClear(); 
>         JNU_ThrowNullPointerException(env, "canvas");
>     } else {            
>         PDATA pData = JNI_GET_PDATA(canvas);
>         if (pData == NULL) {
>             env->DeleteGlobalRef(canvas);
>             THROW_NULL_PDATA_IF_NOT_DESTROYED(canvas);
>         } else {            
>             AwtCanvas *c = (AwtCanvas*)pData;
>             c->m_eraseBackground = sebs->doErase;
>             c->m_eraseBackgroundOnResize = sebs->doEraseOnResize;
>             env->DeleteGlobalRef(canvas);
>         }                   
>     }                        
>     delete sebs;            
> }

Bumping, @prrace?

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1809552512

From abhiscxk at openjdk.org  Tue Nov 14 07:09:27 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 14 Nov 2023 07:09:27 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
In-Reply-To: <BwvctAcFS0lydNNJwqQAy5E17XlhEVRtunISD8io25M=.93a56b10-2bcc-41d1-bbcc-27f46a0282ed@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <BwvctAcFS0lydNNJwqQAy5E17XlhEVRtunISD8io25M=.93a56b10-2bcc-41d1-bbcc-27f46a0282ed@github.com>
Message-ID: <6BikBxrPnwWw-8COtSImapKoXK9eEt6jz3xKAnVtfvk=.9ad1aac8-c9c1-423e-a539-bad4e9839174@github.com>

On Fri, 10 Nov 2023 21:10:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 79:
> 
>> 77: 
>> 78:                 BufferedImage borderPaintedImg =
>> 79:                         robot.createScreenCapture(new Rectangle(pt.x, pt.y,
> 
> I think the test can be simplified by rendering the progress bar into the buffered image directly.

I couldn't understand. Can you please explain a bit more?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1392081231

From tr at openjdk.org  Tue Nov 14 09:55:42 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 14 Nov 2023 09:55:42 GMT
Subject: Integrated: 8210807: Printing a JTable with a JScrollPane prints table
 without rows populated
In-Reply-To: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
References: <deOt_HL4n0ZSg360Aw4P2HeqzR8DNOzbgdn-rwX6JwA=.1c0acebc-c065-4925-8937-7621c37a234b@github.com>
Message-ID: <132Gw1nAvL814M-cnr-Amm8iPvncBBAwTh5VIRrV56k=.3987f7d4-e4c4-4a96-a072-9be55518d4f5@github.com>

On Wed, 8 Nov 2023 07:32:52 GMT, Tejesh R <tr at openjdk.org> wrote:

> `BackingStore` uses its own Graphics to Paint the Image. This is fine when we want to paint it on a Window/Frame, but fails to print. Since `WPathGraphics` is used for Printing, backing store fails to print it and backing store uses newly created `SunGraphics2D` always. The proposed fix is to ignore `backingstore` graphics if passed on Graphics is different from `SunGraphics2D` which ensures the Image is painted on Window and also printed when required. 
> The fix is tested in CI and doesn't cause any regression. The test is verified manually.

This pull request has now been integrated.

Changeset: 95bd92a5
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95bd92a5601afdf02b9d62cab7dbae93f297df47
Stats:     195 lines in 3 files changed: 189 ins; 0 del; 6 mod

8210807: Printing a JTable with a JScrollPane prints table without rows populated

Reviewed-by: psadhukhan, abhiscxk

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

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

From duke at openjdk.org  Tue Nov 14 10:12:35 2023
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Tue, 14 Nov 2023 10:12:35 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v10]
In-Reply-To: <-23zjAMiaToCpf-YQY_kcUKUrfcyOODcFFPh0Dpym-E=.2f0c0300-58a5-4e74-8049-67dbb71a9941@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <-23zjAMiaToCpf-YQY_kcUKUrfcyOODcFFPh0Dpym-E=.2f0c0300-58a5-4e74-8049-67dbb71a9941@github.com>
Message-ID: <DNhI7XCv3ok9aitF2RzUmLQjQezh2F7WKhyzCVmTk0A=.2484d6e9-7b14-47a2-8a51-dd1912cd0709@github.com>

On Mon, 16 Oct 2023 00:56:35 GMT, ??? <duke at openjdk.org> wrote:

>> Candidat box can moving with caret on windows version. Someone must wrote codes for linux(ubuntu), but it doesn't work, so he didn't commit the codes. Why it doesn't work, is the key problem.
>> 
>> 1, I wrote a example for linux:
>> https://github.com/quantum6/X11InputMethod
>> 
>> I tried all parameters to test and as my research:
>> If you use XIMPreeditCallbacks to initiate, the box can't be moved with caret.
>> If you use XIMPreeditNothing, it works.
>> All examples use XIMPreeditCallbacks to initiate input method and candidate box can't moving. So I understand why he didn't commit the codes.
>> 
>> 2, I traced the route of transfering caret coordites on windows version, then add codes for linux.
>> 3, Taishan Office(like Microsoft Office Word) is running on jdk, we tested for a long time, it works OK.
>> 4, I am not sure for AIX( no environment).
>> 
>> 
>> JDK-8264728 : When use chinese IME, the candidate box isn't moved with caret of JTextArea
>> Type: Bug
>> Component: client-libs
>> Sub-Component: java.awt:i18n
>> Affected Version: 8,9,15,16
>> Priority: P3
>> Status: Open
>> Resolution: Unresolved
>> OS: linux
>> CPU: x86_64
>
> ??? 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' of https://github.com/openjdk/jdk into quantum6
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Update to lastest
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - Remove tab
>  - Update to latest and make code safer
>  - Merge branch 'master' of https://github.com/openjdk/jdk into quantum6
>  - 8264728: When use chinese IME, the candidate box isn't moved with caret of JTextArea

hello

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

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1809908298

From tr at openjdk.org  Tue Nov 14 10:18:29 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 14 Nov 2023 10:18:29 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <1QYTaJt7Tk7QWJFcpXNoiz-xcEmtSpo0iTICOug_jlU=.7d709183-b66f-4410-b8b1-4460ba4665b4@github.com>

On Fri, 10 Nov 2023 13:50:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSSBackgroundImage.equals() is implemented

Looks good to me.

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16613#pullrequestreview-1729386160

From psadhukhan at openjdk.org  Tue Nov 14 11:10:06 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 14 Nov 2023 11:10:06 GMT
Subject: RFR: 8315986: javax/swing/JMenuItem/4654927/bug4654927.java:
 component must be showing on the screen to determine its location [v5]
In-Reply-To: <ec7RoH3IAYdtNp4MvRoU7Kv30vn3NSfueOr0JZ8ZfSo=.51674fdc-a808-4d8c-a560-d3471151d95f@github.com>
References: <ec7RoH3IAYdtNp4MvRoU7Kv30vn3NSfueOr0JZ8ZfSo=.51674fdc-a808-4d8c-a560-d3471151d95f@github.com>
Message-ID: <Ojk0z3EMpfEOrx52jC7Sddx1odKph_LGRavaEoN_CdI=.d29df9ba-100a-46fc-ad55-7ecfccf38ce0@github.com>

> Test was run without waiting for UI to be made visible leading to IllegalComponentStateException.
> Used robot.delay consistent with other headful tests to made the test wait after UI is created and shown.
> 
> Test passed in several iterations in all platforms. Link in JBS

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

  Optimize test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15677/files
  - new: https://git.openjdk.org/jdk/pull/15677/files/291706fd..268b995b

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

  Stats: 41 lines in 1 file changed: 9 ins; 27 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15677.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15677/head:pull/15677

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

From aivanov at openjdk.org  Tue Nov 14 15:45:32 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 14 Nov 2023 15:45:32 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <rddNg-lUBkhr_Bip44qK6afaZClhzcB3EVFdnYAUQuI=.6ae3c1ef-cfc4-4b77-992e-f93f8b46b468@github.com>

On Fri, 10 Nov 2023 13:50:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSSBackgroundImage.equals() is implemented

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/text/html/CSS/CSSAttributeEqualityBug.java line 1:

> 1: /*

Please add 8318113 to the `@bug` tag in the test.

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

PR Review: https://git.openjdk.org/jdk/pull/16613#pullrequestreview-1730058566
PR Review Comment: https://git.openjdk.org/jdk/pull/16613#discussion_r1392808012

From aivanov at openjdk.org  Tue Nov 14 15:56:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 14 Nov 2023 15:56:33 GMT
Subject: RFR: 8315986: javax/swing/JMenuItem/4654927/bug4654927.java:
 component must be showing on the screen to determine its location [v5]
In-Reply-To: <Ojk0z3EMpfEOrx52jC7Sddx1odKph_LGRavaEoN_CdI=.d29df9ba-100a-46fc-ad55-7ecfccf38ce0@github.com>
References: <ec7RoH3IAYdtNp4MvRoU7Kv30vn3NSfueOr0JZ8ZfSo=.51674fdc-a808-4d8c-a560-d3471151d95f@github.com>
 <Ojk0z3EMpfEOrx52jC7Sddx1odKph_LGRavaEoN_CdI=.d29df9ba-100a-46fc-ad55-7ecfccf38ce0@github.com>
Message-ID: <gFhvy_-0yrYcH5AWmC9Xd1x0MlVyte34UQ0OnZX2a5I=.7a5023ab-49bf-4a76-9b03-360b6da2404c@github.com>

On Tue, 14 Nov 2023 11:10:06 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test was run without waiting for UI to be made visible leading to IllegalComponentStateException.
>> Used robot.delay consistent with other headful tests to made the test wait after UI is created and shown.
>> 
>> Test passed in several iterations in all platforms. Link in JBS
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize test

Looks good except for the minor comment.

test/jdk/javax/swing/JMenuItem/4654927/bug4654927.java line 79:

> 77:             robot.delay(250);
> 78: 
> 79:             System.out.println("MenuItem LocationOnScreen " + menuItem.getLocationOnScreen());

Line 79 is redundant, it prints the same location that's printed on line 81.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15677#pullrequestreview-1730074554
PR Review Comment: https://git.openjdk.org/jdk/pull/15677#discussion_r1392817958

From azvegint at openjdk.org  Tue Nov 14 17:14:55 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 14 Nov 2023 17:14:55 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux
 with Wayland [v3]
In-Reply-To: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
Message-ID: <ih01YnRFqV5E15L1dhSLrgMSWtn3RmLYa75-7Y4r3Io=.ce7b07d2-f7d0-4466-842d-63758b1e4d21@github.com>

> This is the fix for the regression introduced in [JDK-8280993](https://bugs.openjdk.org/browse/JDK-8280993).
> 
> That fix was to dismiss a popup if the owner loses the window focus when running in Wayland, and didn't take into account that the popup itself can be focusable.
> 
> This fix closes the popup only if the focus moves away from the calling window and the popup itself.
> 
> There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).

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

  Increase the number of columns to fit the text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16636/files
  - new: https://git.openjdk.org/jdk/pull/16636/files/06850c0d..6590a995

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

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

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

From honkar at openjdk.org  Tue Nov 14 18:46:40 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 14 Nov 2023 18:46:40 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
Message-ID: <Ndr8I4_64A91LVUSqonnsFLBiLe5Oavq2Lx5T5Xbrv4=.5a1cfd45-b03e-4731-80cf-8b8f7dd18c27@github.com>

On Fri, 10 Nov 2023 21:26:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It can be null if the NSApplication was created by code outside of AWT. Specifically, in the case of an FX or SWT toolkit, but in theory a native application using JAWT could do this.
>> 
>> In practice, since we haven't even seen a crash as a result of this, I doubt that this code is ever called if AWT isn't running the event loop and hasn't installed their delegate.
>
> To access any native code in AWT the app should initially init the LWCToolkit which sets that application delegate if it is not set already. Do we know how the FX can bypass that initialization?

@mrserb Based on testing so far (tested for following cases - Pure AWT/Swing, Pure FX, Swing components embedded in FX window and FX components embedded in Swing window), there hasn't been a scenario where the shared delegate has been null even in  FX embedded case. As @prrace, @kevinrushforth mentioned earlier, I was thinking of the case where NSApp is created by code outside of AWT and perhaps it fails to install its delegate. The present null checks were added keeping the above scenario in mind.

I'll do some more testing and get back to you on your question - _"if shared delegate can be null at the above locations"_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1393059684

From prr at openjdk.org  Tue Nov 14 20:41:50 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 14 Nov 2023 20:41:50 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v26]
In-Reply-To: <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
Message-ID: <3OHVn3hWJfdS-wYbrMCkS2dhWFEtB_wV3ZcfmUU7sZQ=.64d1f7eb-783b-49e6-90f9-a5b7753421d2@github.com>

On Fri, 10 Nov 2023 10:17:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment awt_DnDDS.cpp

I don't think we should introduce any std:: library support to resolve this.
I'm also fairly sure you can't static link those libraries any more.
The pattern I showed is much cleaner and that's what I want to see here.

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1811232844

From achung at openjdk.org  Tue Nov 14 21:29:51 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 14 Nov 2023 21:29:51 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode on
 different keyboard layouts
Message-ID: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>

Updated previous fix (8262945) to work on extendedKeyCodes. Updated AcceleratorTest to use PassFailJFrame instead of Applet

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

Commit messages:
 - added tags to test
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8315701
 - init commit

Changes: https://git.openjdk.org/jdk/pull/16664/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16664&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315701
  Stats: 434 lines in 7 files changed: 91 ins; 264 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/16664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16664/head:pull/16664

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

From kizune at openjdk.org  Tue Nov 14 21:47:32 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 14 Nov 2023 21:47:32 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
Message-ID: <4d1a4kDPZfnfRWeinv3PloYiHDoNp7RDmZZL5zP7Xvs=.d7d29a7a-0639-4c62-b553-77bc5ba23add@github.com>

On Thu, 9 Nov 2023 22:30:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> 
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   local var reused

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16569#pullrequestreview-1730863622

From duke at openjdk.org  Tue Nov 14 22:54:39 2023
From: duke at openjdk.org (Alec Su)
Date: Tue, 14 Nov 2023 22:54:39 GMT
Subject: Integrated: 8301310: The SendRawSysexMessage test may cause a JVM
 crash
In-Reply-To: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
Message-ID: <gWRFsnVkYausAI_joxCpqRcpV9ego1Z5luG0JTq1uu4=.e08b5681-51fe-48f6-89bd-4037ffd3bd57@github.com>

On Thu, 2 Nov 2023 13:55:41 GMT, Alec Su <duke at openjdk.org> wrote:

> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
> 
> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
> 
> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
> 
> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
> 
> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.

This pull request has now been integrated.

Changeset: d725b73d
Author:    Alec Su <ae40515 at yahoo.com.tw>
Committer: Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d725b73df01ae4478dfaabc47c48cd7231d91afa
Stats:     19 lines in 2 files changed: 13 ins; 0 del; 6 mod

8301310: The SendRawSysexMessage test may cause a JVM crash

Reviewed-by: serb

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

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

From jwaters at openjdk.org  Wed Nov 15 01:49:42 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 15 Nov 2023 01:49:42 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v26]
In-Reply-To: <3OHVn3hWJfdS-wYbrMCkS2dhWFEtB_wV3ZcfmUU7sZQ=.64d1f7eb-783b-49e6-90f9-a5b7753421d2@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
 <3OHVn3hWJfdS-wYbrMCkS2dhWFEtB_wV3ZcfmUU7sZQ=.64d1f7eb-783b-49e6-90f9-a5b7753421d2@github.com>
Message-ID: <XjaVAqXf0ZqzuHMxoKVWPtmBGe_oU4Gpdv7bGWYVa2U=.3c9b8134-b176-48af-a26a-9f665df3be00@github.com>

On Tue, 14 Nov 2023 20:39:07 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't think we should introduce any std:: library support to resolve this. I'm also fairly sure you can't static link those libraries any more. The pattern I showed is much cleaner and that's what I want to see here.

It is still possible to link them statically, we do indeed statically link those libraries in other places too, for instance in jdk.accessibility, see https://github.com/openjdk/jdk/blob/d9a89c59daa40fdc8da620940d5c518a9f18bc7b/make/modules/jdk.accessibility/Lib.gmk#L44

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1811669416

From tr at openjdk.org  Wed Nov 15 04:41:30 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 15 Nov 2023 04:41:30 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
Message-ID: <NN7oNkY4seV4ySid-m1wn8HH5JM9ijyVyjHmG3QjkIA=.65693057-9b92-4469-9042-13d4c34680a3@github.com>

On Wed, 8 Nov 2023 08:49:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
>> similar to how header is painted
> 
> Can you please point to the code where the header is painted similarly?

@prsadhuk @DamonGuy Any further suggestions/comments ?

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

PR Comment: https://git.openjdk.org/jdk/pull/16374#issuecomment-1811796976

From serb at openjdk.org  Wed Nov 15 06:50:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 15 Nov 2023 06:50:36 GMT
Subject: RFR: 8319985: Delete sun.awt.windows.WToolkit.embedded*() API
Message-ID: <d1j-bRmojRZ1-KgV3Q6kmsU6c5TONl1AxPfYBEwkWug=.35131da9-dfa6-4f2f-a09f-10adf73de1d1@github.com>

Unused "embedded.." methods in the "sun.awt.windows.WToolkit" class were deleted.

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

Commit messages:
 - Update awt_Toolkit.cpp
 - Merge remote-tracking branch 'upstream/master' into emb
 - Delete sun.awt.windows.WToolkit.embedded*() API

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

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

From psadhukhan at openjdk.org  Wed Nov 15 07:03:55 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Nov 2023 07:03:55 GMT
Subject: RFR: 8315986: [macos14]
 javax/swing/JMenuItem/4654927/bug4654927.java: component must be showing on
 the screen to determine its location [v6]
In-Reply-To: <ec7RoH3IAYdtNp4MvRoU7Kv30vn3NSfueOr0JZ8ZfSo=.51674fdc-a808-4d8c-a560-d3471151d95f@github.com>
References: <ec7RoH3IAYdtNp4MvRoU7Kv30vn3NSfueOr0JZ8ZfSo=.51674fdc-a808-4d8c-a560-d3471151d95f@github.com>
Message-ID: <ezJwV3yi2Exkcbg4rBrQsxRpo_9xJEQVkDNgLX0W2S0=.ca2edcb2-51b7-4ef8-ba2b-839e36d69eb2@github.com>

> Test was run without waiting for UI to be made visible leading to IllegalComponentStateException.
> Used robot.delay consistent with other headful tests to made the test wait after UI is created and shown.
> 
> Test passed in several iterations in all platforms. Link in JBS

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

  Remove redundant println

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15677/files
  - new: https://git.openjdk.org/jdk/pull/15677/files/268b995b..c2688eb2

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

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

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

From psadhukhan at openjdk.org  Wed Nov 15 07:03:56 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 15 Nov 2023 07:03:56 GMT
Subject: Integrated: 8315986: [macos14]
 javax/swing/JMenuItem/4654927/bug4654927.java: component must be showing on
 the screen to determine its location
In-Reply-To: <ec7RoH3IAYdtNp4MvRoU7Kv30vn3NSfueOr0JZ8ZfSo=.51674fdc-a808-4d8c-a560-d3471151d95f@github.com>
References: <ec7RoH3IAYdtNp4MvRoU7Kv30vn3NSfueOr0JZ8ZfSo=.51674fdc-a808-4d8c-a560-d3471151d95f@github.com>
Message-ID: <c3EHU-eT-sEL_UeFZK8SBwTZIlx5uV1IUu4XNOQk1a4=.8269aec8-9f98-49c7-ba59-4fd8191befec@github.com>

On Tue, 12 Sep 2023 04:45:51 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test was run without waiting for UI to be made visible leading to IllegalComponentStateException.
> Used robot.delay consistent with other headful tests to made the test wait after UI is created and shown.
> 
> Test passed in several iterations in all platforms. Link in JBS

This pull request has now been integrated.

Changeset: e7486e8c
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7486e8cfc9a3f5cbe3515c68e325a25863c162e
Stats:     72 lines in 1 file changed: 22 ins; 30 del; 20 mod

8315986: [macos14] javax/swing/JMenuItem/4654927/bug4654927.java: component must be showing on the screen to determine its location

Reviewed-by: dnguyen, honkar, aivanov

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

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

From abhiscxk at openjdk.org  Wed Nov 15 08:08:59 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 15 Nov 2023 08:08:59 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel"
Message-ID: <wZgui2Dqz6jHt1WibwroyISlqjmFvJ-syCS8DonkYi0=.6e444c80-2196-4233-9113-a0ae855b3e9a@github.com>

The test fails for filechooser selection mode set to `DIRECTORIES_ONLY`. For DIRECTORIES_ONLY mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
Tested the current change on the machine it failed for multiple times, no failure observed.
CI link attached in JBS.

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

Commit messages:
 - Test fix
 - Remove frame dispose
 - JTabbedPane arrow direction fix

Changes: https://git.openjdk.org/jdk/pull/16671/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16671&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319938
  Stats: 152 lines in 3 files changed: 135 ins; 5 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/16671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16671/head:pull/16671

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

From abhiscxk at openjdk.org  Wed Nov 15 08:12:39 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 15 Nov 2023 08:12:39 GMT
Subject: Withdrawn: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel"
In-Reply-To: <wZgui2Dqz6jHt1WibwroyISlqjmFvJ-syCS8DonkYi0=.6e444c80-2196-4233-9113-a0ae855b3e9a@github.com>
References: <wZgui2Dqz6jHt1WibwroyISlqjmFvJ-syCS8DonkYi0=.6e444c80-2196-4233-9113-a0ae855b3e9a@github.com>
Message-ID: <zOEwXsoLVGpeEyJJlpQhPFWAyAvAtOQ3GdVixyv3OqQ=.403a7e00-5f9d-4856-8480-f77abc0837d5@github.com>

On Wed, 15 Nov 2023 08:03:34 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> The test fails for filechooser selection mode set to `DIRECTORIES_ONLY`. For DIRECTORIES_ONLY mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Wed Nov 15 08:45:35 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 15 Nov 2023 08:45:35 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <OS7qTXfAW4RRmag_sHLK-4WXZeK_QsNpS8nDP0qQkwg=.a7b199f1-103e-4e85-8400-e0339c24b186@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

In the meantime,   https://bugs.openjdk.org/browse/JDK-8295159  was integrated.
There we restore on x86_64 and aarch the floating point environment  (fenv_t)  after loading libs in HS os::dll_load / dlopen_helper to avoid  'silent' manipulation of the fenv by 'bad' shared libs.
But unfortunately this does not work for  libs  not going through this coding (like the ones loaded from JDK c code).

 (And even if restoring in these additional cases is not wanted, we could at least *warn* about the change by a trace .)

Might be worth considering in context of this change .

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

PR Comment: https://git.openjdk.org/jdk/pull/15264#issuecomment-1812023112

From abhiscxk at openjdk.org  Wed Nov 15 09:56:39 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 15 Nov 2023 09:56:39 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel"
Message-ID: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>

The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
Tested the current change on the machine it failed for multiple times, no failure observed.
CI link attached in JBS.

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

Commit messages:
 - Test fix

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

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

From jdv at openjdk.org  Wed Nov 15 15:56:45 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 15 Nov 2023 15:56:45 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
Message-ID: <ohhR9XAdmwUmUXNf5Wfy2mrzdMOpAuddjzyqxYyFpZ4=.08df2b77-72ec-4a99-ae73-cd5c995b0f94@github.com>

On Wed, 25 Oct 2023 23:42:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

src/java.desktop/share/classes/sun/font/HBShaper.java line 66:

> 64:      * };
> 65:      */
> 66:    private static final UnionLayout VarIntLayout = MemoryLayout.unionLayout(

Indentation issue.

src/java.desktop/share/classes/sun/font/HBShaper.java line 84:

> 82:      * };
> 83:      */
> 84:      private static final StructLayout PositionLayout = MemoryLayout.structLayout(

Indentation issue.

src/java.desktop/share/classes/sun/font/HBShaper.java line 142:

> 140:     private static final MemorySegment get_contour_pt_stub;
> 141: 
> 142:     private static final MemorySegment store_layout_results_stub;

I see this Upcall is named `store_layout_results` in case of FFM and we call it similar function in JNI case as `storeGVData`. If we can find some common name and use it will be beneficial in future when we want to compare code between FFM and JNI implementation.

src/java.desktop/share/classes/sun/font/HBShaper.java line 144:

> 142:     private static final MemorySegment store_layout_results_stub;
> 143: 
> 144:    private static FunctionDescriptor

Indentation issue.

src/java.desktop/share/classes/sun/font/HBShaper.java line 153:

> 151:    }
> 152: 
> 153:    private static MethodHandle getMethodHandle

Indentation issue.

src/java.desktop/share/classes/sun/font/HBShaper.java line 165:

> 163:    }
> 164: 
> 165:    static {

Indentation issue.

src/java.desktop/share/classes/sun/font/HBShaper.java line 212:

> 210:         jdk_hb_shape_handle = tmp4;
> 211: 
> 212:         Arena garena = Arena.global(); // creating stubs that exist until VM exit.

Variable name `gArena`(for global arena) is better than using `garena`.

src/java.desktop/share/classes/sun/font/HBShaper.java line 347:

> 345:         glyphIDPtr.setAtIndex(JAVA_INT, 0, glyphID);
> 346:         return (glyphID != 0) ? 1 : 0;
> 347: }

Indentation issue.

src/java.desktop/share/classes/sun/font/HBShaper.java line 659:

> 657:         startPt.y = advY;
> 658:         startPt.x = advX;
> 659:   }

Indentation issue.

src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 193:

> 191:         } else {
> 192:            long pFace = getFacePtr(font);
> 193:             shape(font, strike, ptSize, mat, pFace,

Is it okay to not have `(pFace != 0)` check here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394338584
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394339310
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394403920
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394339849
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394340526
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394341308
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394370065
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394342419
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394345302
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1394293925

From duke at openjdk.org  Wed Nov 15 16:24:46 2023
From: duke at openjdk.org (Alec Su)
Date: Wed, 15 Nov 2023 16:24:46 GMT
Subject: RFR: 8301310: The SendRawSysexMessage test may cause a JVM crash
In-Reply-To: <ncVv6ewG-gQGZJ8P9jncykLCqmofuEBoedUMkS7tQcU=.4e8c01f1-ffa9-49c3-89ba-bf1f3ba64729@github.com>
References: <rXppAV1CquPVOB1oci3zMp9MG50te3SrsYrr5gjbKUc=.2a17e859-69cf-4fb4-8d1c-e8e995def4fa@github.com>
 <ncVv6ewG-gQGZJ8P9jncykLCqmofuEBoedUMkS7tQcU=.4e8c01f1-ffa9-49c3-89ba-bf1f3ba64729@github.com>
Message-ID: <-hYsdu4gxdmF0o4LiViZUskCeqMLw2lzaiAVXPdIu8E=.2fbdf9d6-992b-439c-9667-f8b52a58775c@github.com>

On Mon, 6 Nov 2023 18:45:41 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The bug on Windows doesn't generate any error messages. During the testcase run, every "Open MIDI port" message should be followed by an "All SysexMessage sent" message. Alternatively, you can check `%ERRORLEVEL%` to determine if there's an error when JVM exits.
>> 
>> On Linux, there are no software MIDI devices provided by default. To reproduce this bug on Linux, you need to connect a real MIDI device to Linux or create a virtual MIDI device by running the command `sudo modprobe snd_virmidi midi_devs=1`.
>> 
>> The bug occurred because a pointer was increased on Line 137, then it attempted to release the modified pointer on Line 143.
>> 
>> https://github.com/openjdk/jdk/blob/e9d19d0fffc47119d0d4f756833ec87cd0a6331e/src/java.desktop/share/native/libjsound/MidiOutDevice.c#L128-L144
>> 
>> To fix this, I added a variable `msg` to store the modified pointer to prevent `data` pointer being modified.
>
> It seems the bug is a duplicate of the next one https://bugs.openjdk.org/browse/JDK-8301310 ?

@mrserb Many thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16477#issuecomment-1812851700

From duke at openjdk.org  Wed Nov 15 16:26:56 2023
From: duke at openjdk.org (Alec Su)
Date: Wed, 15 Nov 2023 16:26:56 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v5]
In-Reply-To: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
Message-ID: <nWuQnby5zX6jhBN1JYULcLryeHYVAgP5_468kOLUmuM=.dc2da099-aa7e-42fd-a08f-b7959484e222@github.com>

> JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.
> 
> The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.
> 
> 
> import javax.sound.midi.*;
> 
> public class MidiTest {
>     public static class RawMidiMessage extends MidiMessage {
>         public RawMidiMessage(byte[] data) {
>             super(data);
>         }
> 
>         @Override
>         public Object clone() {
>             return new RawMidiMessage(this.getMessage());
>         }
>     }
> 
>     public static void main(String[] args) {
>         var deviceInfos = MidiSystem.getMidiDeviceInfo();
>         for (var info : deviceInfos) {
>             try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
>                 if (device.getMaxReceivers() != 0) {
>                     System.out.println("Open MIDI port: " + info.getName());
>                     device.open();
>                     Receiver receiver = device.getReceiver();
>                     // Send two sysex messages at once
>                     receiver.send(new RawMidiMessage(new byte[]{
>                             (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
>                             (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
>                         }), -1);
>                     // Send another sysex message
>                     receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
>                 }
>             } catch (MidiUnavailableException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
> 
> 
> The expected messages received should be the following three messages
> 
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
> 
> 
> But acually four messages was received with the second message repeated twice.
> 
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
> F0 7D 02 F7
> 
> 
> To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buffer hasn't been freed due to an error.
> 
> It seems that the patch may also resolve JDK-8250667. The extra bytes in the s...

Alec Su 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:

 - Remove the testcase and reuse the testcase added in #16477
 - Merge branch 'master' into sysex-win
 - Remove OS check in the test
 - Code cleanup
 - Add a testcase for the buffer issue on Windows
 - Resolve the message size issue when sending SysexMessage on Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16399/files
  - new: https://git.openjdk.org/jdk/pull/16399/files/4ae4486b..18283c4a

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

  Stats: 646048 lines in 1585 files changed: 98010 ins; 479653 del; 68385 mod
  Patch: https://git.openjdk.org/jdk/pull/16399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16399/head:pull/16399

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

From duke at openjdk.org  Wed Nov 15 16:26:57 2023
From: duke at openjdk.org (Alec Su)
Date: Wed, 15 Nov 2023 16:26:57 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: <qaDCpWySofOiOBvvJo6cOjcUyTd8KGmSf7siquH48O4=.820c58c7-d092-4bdf-a450-182a812de3ff@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
 <4BEUq2T444DW7RJq0Dy3IMpfoT7DHsWiRFxdGb_tvuc=.35afe82b-0dd9-4878-a2eb-0465be00f182@github.com>
 <4mxaIfPVLG8XrFEX4c8esFSe_8rPDJ_8uPiygl2f1vc=.34203b0c-6662-4d3a-bd82-2f36917012c1@github.com>
 <qaDCpWySofOiOBvvJo6cOjcUyTd8KGmSf7siquH48O4=.820c58c7-d092-4bdf-a450-182a812de3ff@github.com>
Message-ID: <rkssMKGZP3e2nwIzJK1b6cCBVE7Zd1hco7YiTjUHmJs=.74e93dd9-ad58-4f5d-9c9b-1db851f9d467@github.com>

On Tue, 7 Nov 2023 16:17:19 GMT, Alec Su <duke at openjdk.org> wrote:

>> The test is useful since that is the only test that touches the code path when the buffer for the midi message is reused and the bug can be reproduced. at least it doesn't crash.
>
> Actually I noticed the bug when I was working on https://github.com/openjdk/jdk/pull/16477. The testcase I added in the PR also triggered the bug. However, the testcase crashes JVM before triggering the bug, so I use another testcase for this PR.
> 
> The test case sends the folloing three pieces of sysex message
> 
> F0 7D 01 02
> F7 03 04
> F7 05 06 07 F7
> 
> 
> The expected message received should be the following
> 
> F0 7D 01 02 03 04 05 06 07 F7
> 
> 
> But the acual message received is
> 
> F0 7D 01 02 03 04 01 02 05 06 07 F7
> 
> 
> Therefore, I'm not sure whether it's better to remove the testcase in this PR or keep it.

I removed the testcase and reuse the testcase added in #16477.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16399#discussion_r1394451199

From prr at openjdk.org  Wed Nov 15 18:49:39 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 18:49:39 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel"
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <GVM9j4TqcBEcX5-G-YsV3AFu41_Bel8Ilb-epLq5k_0=.9ac66d68-75cc-4ed2-8bf2-4e06f23fd462@github.com>

On Wed, 15 Nov 2023 09:50:19 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 46:

> 44:  * @run main TestFileChooserSingleDirectorySelection
> 45:  */
> 46: 

I don't know why it was necessary to move all around all the above lines.
And whilst import java.io sorts after java.awt, it is long standing convention that the "core"
packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones. This is true of product source as well as tests.
So you should just undo all of the above except for adding the new bug id.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 66:

> 64:             // create test directory
> 65:             String tmpDir = System.getProperty("user.home");
> 66: 

Does this test HAVE to use the home dir to create the temporary folders and files ?
Is there some reason some part of the test absolutely requires the home directory ?
It isn't obvious to me.
Why can't you instead use  System.getProperty("java.io.tmpdir");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1394632505
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1394641413

From prr at openjdk.org  Wed Nov 15 18:51:32 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 18:51:32 GMT
Subject: RFR: 8319985: Delete sun.awt.windows.WToolkit.embedded*() API
In-Reply-To: <d1j-bRmojRZ1-KgV3Q6kmsU6c5TONl1AxPfYBEwkWug=.35131da9-dfa6-4f2f-a09f-10adf73de1d1@github.com>
References: <d1j-bRmojRZ1-KgV3Q6kmsU6c5TONl1AxPfYBEwkWug=.35131da9-dfa6-4f2f-a09f-10adf73de1d1@github.com>
Message-ID: <x1hjDz2KNCWQ7f8ffOK1oVDB67QBT27iuN7hSdxAQyY=.cf310e44-9b9b-46b2-ac5b-87961700fdfa@github.com>

On Mon, 13 Nov 2023 20:44:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Unused "embedded.." methods in the "sun.awt.windows.WToolkit" class were deleted.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16640#pullrequestreview-1732713705

From prr at openjdk.org  Wed Nov 15 19:14:34 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 19:14:34 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux
 with Wayland [v3]
In-Reply-To: <ih01YnRFqV5E15L1dhSLrgMSWtn3RmLYa75-7Y4r3Io=.ce7b07d2-f7d0-4466-842d-63758b1e4d21@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
 <ih01YnRFqV5E15L1dhSLrgMSWtn3RmLYa75-7Y4r3Io=.ce7b07d2-f7d0-4466-842d-63758b1e4d21@github.com>
Message-ID: <V8Al-dcSOw0Ko-HGk5VDa5NlmIwU6iCgEaNoUEYomjY=.77fdb5d3-e425-41e7-ade7-0d1b3318aa5f@github.com>

On Tue, 14 Nov 2023 17:14:55 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is the fix for the regression introduced in [JDK-8280993](https://bugs.openjdk.org/browse/JDK-8280993).
>> 
>> That fix was to dismiss a popup if the owner loses the window focus when running in Wayland, and didn't take into account that the popup itself can be focusable.
>> 
>> This fix closes the popup only if the focus moves away from the calling window and the popup itself.
>> 
>> There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Increase the number of columns to fit the text

Marked as reviewed by prr (Reviewer).

test/jdk/javax/swing/JPopupMenu/FocusablePopupDismissTest.java line 60:

> 58: 
> 59:             While the popup is displayed, click on a some system window.
> 60:             If the popup has disappeared, click Pass, otherwise click Fail.

"click on some other window on the desktop."

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

PR Review: https://git.openjdk.org/jdk/pull/16636#pullrequestreview-1732724827
PR Review Comment: https://git.openjdk.org/jdk/pull/16636#discussion_r1394651526

From prr at openjdk.org  Wed Nov 15 19:16:30 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 19:16:30 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <0zSYoNexz1sYJt9deI0mtk21LxO9aom_RnMMOIdWbcU=.18b898d0-cac7-49af-b502-8172ca3be3a5@github.com>

On Fri, 10 Nov 2023 13:50:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSSBackgroundImage.equals() is implemented

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16613#pullrequestreview-1732749217

From dnguyen at openjdk.org  Wed Nov 15 19:19:42 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 15 Nov 2023 19:19:42 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
 <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
Message-ID: <brio-R7SyRbaEVJbGT69o4M8kt2ORANLsKF49MyK0Ec=.4bbb05f9-801c-4333-9168-16f3ddedb15c@github.com>

On Tue, 7 Nov 2023 04:11:22 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 121:
>> 
>>> 119:     private static void saveImage(BufferedImage image, String fileName) {
>>> 120:         try {
>>> 121:             ImageIO.write(image, "png", new File(fileName));
>> 
>> Is it OK to save an image here? In the past, I stored my images similar to in #7310 to store the image in the correct area for temporary images for a test.
>
> U mean to create a test directory and store image there?

Not a new test directory. In that referenced PR, I had to get the path to the directory where test files are stored temporarily. This helps with testing mainly.

`Path.of(System.getProperty("test.classes", "."));` was the path I used in the PR. I saved it to a var and wrote the image to that var followed by the image name.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394670882

From dnguyen at openjdk.org  Wed Nov 15 19:19:40 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 15 Nov 2023 19:19:40 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v4]
In-Reply-To: <LUZ0alzQIQIjwMppiucY2kmKe1tRxpB6oLVUSIXDKcw=.bc5558a3-41f2-4557-b9dc-c58ff2e232a8@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <LUZ0alzQIQIjwMppiucY2kmKe1tRxpB6oLVUSIXDKcw=.bc5558a3-41f2-4557-b9dc-c58ff2e232a8@github.com>
Message-ID: <XW1JMlBS-NCW_yWgSVTJbJBbJtT_cEAOFlWAK9sL1bI=.ae3d9a68-753a-4438-85bb-f7f6ef6ba54a@github.com>

On Fri, 10 Nov 2023 07:31:19 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

There's plenty of places where the for loop is missing a space as well. Seems like there are a lot though, so I'll leave it up to you whether or not it should be fixed with this update. Would seem odd to have a space before some () and not after some others.

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

> 2086:                 cellRect = table.getCellRect(row, cMin, false);
> 2087:                 cellRect.x = getXPosition(cMin);
> 2088:                 for(int column = cMin; column <= cMax; column++) {

Suggestion:

            for (int row = rMin; row <= rMax; row++) {
                cellRect = table.getCellRect(row, cMin, false);
                cellRect.x = getXPosition(cMin);
                for (int column = cMin; column <= cMax; column++) {

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

> 2097:             }
> 2098:         } else {
> 2099:             for(int row = rMin; row <= rMax; row++) {

Suggestion:

            for (int row = rMin; row <= rMax; row++) {

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

> 2100:                 cellRect = table.getCellRect(row, cMin, false);
> 2101:                 cellRect.x = getXPosition(cMax);
> 2102:                 for(int column = cMax; column >= cMin; column--) {

Suggestion:

                for (int column = cMax; column >= cMin; column--) {

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 589:

> 587:         int columnWidth;
> 588:         if (table.getComponentOrientation().isLeftToRight()) {
> 589:             for(int row = rMin; row <= rMax; row++) {

Suggestion:

            for (int row = rMin; row <= rMax; row++) {

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 592:

> 590:                 cellRect = table.getCellRect(row, cMin, false);
> 591:                 cellRect.x = getXPosition(cMin);
> 592:                 for(int column = cMin; column <= cMax; column++) {

Suggestion:

                for (int column = cMin; column <= cMax; column++) {

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 603:

> 601:             }
> 602:         } else {
> 603:             for(int row = rMin; row <= rMax; row++) {

Suggestion:

            for (int row = rMin; row <= rMax; row++) {

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 612:

> 610:                     paintCell(context, g, cellRect, row, cMax);
> 611:                 }
> 612:                 for(int column = cMax-1; column >= cMin; column--) {

Suggestion:

                for (int column = cMax-1; column >= cMin; column--) {

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

PR Review: https://git.openjdk.org/jdk/pull/16374#pullrequestreview-1732745770
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394667057
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394666897
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394666771
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394665306
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394665452
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394665628
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1394665829

From prr at openjdk.org  Wed Nov 15 19:30:35 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 19:30:35 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
Message-ID: <YL6MPpDMQbR3WmXkzR4v2PH1vNqkH36DoO7g1cH3qPE=.1c0d846e-defa-4a1e-87e3-78305ff99ea6@github.com>

On Thu, 9 Nov 2023 22:30:32 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> 
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   local var reused

src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 417:

> 415:     if (getenv("AWT_DISABLE_NSDELEGATE_SECURE_SAVE") != NULL) {
> 416:        supportsSecureState = NO;
> 417:     }

I think that (and in the other case), it is best to read the env. var only once, not keep checking it on ever call to this method. Theoretically if someone used putenv/setenv (yes they'd need native code), it would cause us to change the answer.

Yes, this makes the code a bit more complicated but it will be safer.
maybe you could maybe use static locals

<pre>
(BOOL)applicationSupportsSecureRestorableState:(NSApplication *)app {
     static BOOL checked = NO;
     static BOOL supportsSecureState = YES;
     if (checked == NO) {
        checked = YES;
        if (getenv("AWT_DISABLE_NSDELEGATE_SECURE_SAVE") != NULL) {
            supportsSecureState = NO;
     }
     return supportsSecureState;
}
    
</pre>

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1394683107

From prr at openjdk.org  Wed Nov 15 19:38:34 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 19:38:34 GMT
Subject: RFR: 8264728: When use chinese IME,
 the candidate box isn't moved with caret of JTextArea [v2]
In-Reply-To: <_TT5VcQqbLb3a15OZwI1n01NViGr-e28GFaBWTOV7H8=.d54d817d-2583-457d-894e-ca956d8c1b79@github.com>
References: <4JjGitYNWd7jQbHa4_1M6awOvkgtpfd2AY5LKS3MnUM=.8126670d-c076-4756-98be-9b6c7b7a565d@github.com>
 <UqSiy7Xgi1EsOMUQ2FiEWkLhU7LGxPHDpT0KLfemqQw=.a893e45f-9b10-40fd-bf57-8a87e7c69373@github.com>
 <aczaDANDVE57IOrmxBp6TJexgbwzv6Z5kX3ZnEkhWPw=.e20ff74f-073a-425d-b58e-044d5ea1ba0b@github.com>
 <sGr2e6f6xUUVubiIiwT_TUE9KcVKzbrmxER5kFKO_MA=.becc3774-c1f3-448b-819a-22a5f108fb81@github.com>
 <_TT5VcQqbLb3a15OZwI1n01NViGr-e28GFaBWTOV7H8=.d54d817d-2583-457d-894e-ca956d8c1b79@github.com>
Message-ID: <7L1p30l198Cy8vDbN24EPcB61cq9EQfX181fzE5XElA=.5ab6e3de-8a25-4b29-80a2-1cde0afc90c8@github.com>

On Thu, 17 Aug 2023 19:20:03 GMT, Nikita Provotorov <duke at openjdk.org> wrote:

>> @NikitkoCent you wrote "Hi, guys! I want to notice that JetBrains is working on the issue too and we're going to propose our own fix."
>> 
>> So I think we are waiting to see what that might be ..
>> 
>> What is the status of that ? Is there a reason you think you have a better fix ?
>
> @prrace, hello!
> OMG, I didn't know that the review comments don't appear until you press the "Submit review" button. I left them a few months ago and thought that just nobody cared.
> 
> About the plans: I'm going to release a preview build of our JVM (JBR) with the patch solving this problem in a few weeks, polish it according to the feedback and then propose the patch to OpenJDK.

Please read the comments further up, @NikitkoCent wants to propose an alternative fix.
Having said that, we've been waiting on that a long time now, so I hope it shows up soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-1813144085

From shurailine at openjdk.org  Wed Nov 15 19:40:32 2023
From: shurailine at openjdk.org (Alexandre Iline)
Date: Wed, 15 Nov 2023 19:40:32 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v6]
In-Reply-To: <FyVlQDMdF7tji0yw8dEUI9VMRaqayYv0qhvmth_VywQ=.09f4d384-5deb-4c73-82df-7288707d28d2@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <FyVlQDMdF7tji0yw8dEUI9VMRaqayYv0qhvmth_VywQ=.09f4d384-5deb-4c73-82df-7288707d28d2@github.com>
Message-ID: <6z3vbjhGmQftWudwZTADzozUTzWC78PXzQ0tUj3N9vw=.f5acdc5b-1635-4a5b-984a-a56a8fd8cc83@github.com>

On Wed, 8 Nov 2023 09:28:13 GMT, songpv-imt <duke at openjdk.org> wrote:

>> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
>> 
>> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)
>
> songpv-imt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterJVMGetDropSuccessTest.java
>   Change BUTTON1_MASK to BUTTON1_DOWN_MASK because BUTTON1_MASK is deprecated: https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/event/InputEvent.html#BUTTON1_MASK

test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 303:

> 301:             boolean success2 = false;
> 302:             synchronized (Util.SYNC_LOCK) {
> 303:                 robot.mouseRelease(InputEvent.BUTTON1_DOWN_MASK);

I suppose this would work but the code is hard to read.
1. You are synchronizing on SYNC_LOCK on multiple places: sometimes in the listener method and sometimes around the listener methods. It is hard to make sure that the fields are properly guarded.
2. The SYNC_LOCK was originally needed just to call wait/notify, you are using it for more than that now, which is less transparent.
3. Finally the access to the listener's field is already partially guarded as method calls from the drag happen on the AWT event queue. It would be easier to understand if calls to the methods which originates from main would also go through the event queue. That is, after all, the most common approach for the java UI code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1394702525

From prr at openjdk.org  Wed Nov 15 20:28:35 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 20:28:35 GMT
Subject: RFR: JDK-8313764: Offer JVM HS functionality to shared lib load
 operations done by the JDK codebase [v2]
In-Reply-To: <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
References: <vr8HY51aUp9uPQgXK2fF09bR47fXr2e-SYXVNh5olDs=.c0d78d19-3fcb-4b0e-8e15-b0d8cfb02a0a@github.com>
 <L38Vrwzcuhogb_WExsq8DPdoRRYydiBqB6Kb7lzlN5M=.b78aa083-9983-4e77-b673-3d905e9f0bda@github.com>
Message-ID: <c7MhgTyLChABNJuYsisWJb8KBzu01TnSLwSeU0j1Ut0=.d942eefd-51eb-4854-83c6-d695d3d4dbf0@github.com>

On Wed, 23 Aug 2023 15:18:03 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Currently there is a number of functionality that would be interesting to have for shared lib load operations in the JDK C code.
>> Some examples :
>> Events::log_dll_message for hs-err files reporting
>> JFR event NativeLibraryLoad
>> There is the need to update the shared lib Cache on AIX ( see LoadedLibraries::reload() , see also https://bugs.openjdk.org/browse/JDK-8314152 ),
>> this is currently not fully in sync with libs loaded form jdk c-libs and sometimes reports outdated information
>> 
>> Offer an interface (e.g. jvm.cpp) to support this.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   windows aarch64 build issues

src/java.desktop/unix/native/common/awt/fontpath.c line 53:

> 51: /* for dlopen */
> 52: #include <macro_helper.h>
> 53: 

I have no idea why we would want to use some VM internal in the desktop module.
Please take the desktop module changes out of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15264#discussion_r1394756424

From aivanov at openjdk.org  Wed Nov 15 20:39:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 15 Nov 2023 20:39:29 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <u3FrzMe2qOa7i8NBfH_SM681o6KyUckSnQ6TvxTxJAI=.61672e75-485f-43fc-82b8-78af2084612a@github.com>

On Fri, 10 Nov 2023 13:50:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSSBackgroundImage.equals() is implemented

[My recent comment](https://github.com/openjdk/jdk/pull/16613#discussion_r1392808012) removed my approval.

It's *approved* after the following is addressed:

> Please add 8318113 to the @bug tag in the test.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16613#pullrequestreview-1732939378

From azvegint at openjdk.org  Wed Nov 15 22:12:08 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 15 Nov 2023 22:12:08 GMT
Subject: RFR: 8319103: Popups that request focus are not shown on Linux
 with Wayland [v4]
In-Reply-To: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
Message-ID: <8V7_lKNUbOCAklw-UEJfeEXoonNpoj6gtnRLbYqDTxg=.9809f682-0cf8-4762-9459-ad3a96edb818@github.com>

> This is the fix for the regression introduced in [JDK-8280993](https://bugs.openjdk.org/browse/JDK-8280993).
> 
> That fix was to dismiss a popup if the owner loses the window focus when running in Wayland, and didn't take into account that the popup itself can be focusable.
> 
> This fix closes the popup only if the focus moves away from the calling window and the popup itself.
> 
> There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).

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

  instructions update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16636/files
  - new: https://git.openjdk.org/jdk/pull/16636/files/6590a995..c50fb179

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

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

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

From prr at openjdk.org  Wed Nov 15 23:36:34 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 15 Nov 2023 23:36:34 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <ovU11PYqd7tTkGWslJ6ivzGmABWBqa_Lr9I-nyGuMHI=.4f40d3bd-f7c4-40fb-9689-a5193c7af938@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

Alexey has a point. Currently the set* methods are complete no-ops, so that needs to be considered here.

This is an example of what can happen if method A specifies what method B will do :-)
Admittedly these cases are tightly coupled.

About Alexey's example,
I can't figure out what I'm supposed to be learning from the images in the bug report.
Can someone attach somewhere a clear "with methods" vs "without methods" (ie before and after, side-by side screenshot) of what is considered to be the most problematic consequence of removing them ?

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1813459830

From nikita.provotorov at jetbrains.com  Thu Nov 16 00:01:08 2023
From: nikita.provotorov at jetbrains.com (Nikita Provotorov)
Date: Thu, 16 Nov 2023 01:01:08 +0100
Subject: Is it valid to call JComponent#paintImmediately on a non-EDT thread
 (yet)?
Message-ID: <CAMTdVeoVr=xzqsMHXeLdZR09G+O8U_AtwTTGS6xPj2PXTheWJw@mail.gmail.com>

Hello!
I've discovered that on X11 platforms a call
of java.awt.TextComponent#setText can lead to a call
of javax.swing.JComponent#paintImmediately(java.awt.Rectangle) on the same
thread.
Since java.awt.TextComponent#setText is allowed to be called on any thread
(because it's AWT, not Swing), JComponent#paintImmediately may be called
outside of EDT. Is this a valid behavior?

The following stacktrace shows how exactly this can happen:

> at javax.swing.JComponent.paintImmediately
> at sun.awt.X11.XTextAreaPeer$AWTTextArea.repaintNow
> at sun.awt.X11.XTextAreaPeer.repaintText
> at sun.awt.X11.XTextAreaPeer.setText
> at java.awt.TextComponent.setText


Best regards,
Nikita Provotorov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231116/f0f45d6e/attachment.htm>

From serb at openjdk.org  Thu Nov 16 01:57:37 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Nov 2023 01:57:37 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <0NrUdOATwm9ckjU4JesHN7RnvxUtHm7ugDpJ1GAanUA=.63031f7a-1d91-477d-ac64-63a830c2fba6@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
 <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>
 <evGDJiD-l_-ZWqXrr_49mipBrBBq-bOT4AIw0ZvZziY=.6945f131-afc1-47b6-8f3f-edbe3362fb3b@github.com>
 <0NrUdOATwm9ckjU4JesHN7RnvxUtHm7ugDpJ1GAanUA=.63031f7a-1d91-477d-ac64-63a830c2fba6@github.com>
Message-ID: <afyI8LrW67diDlYLn96A7PmjPHH8P8uU6MYhBNWbDek=.c5a97263-0660-42af-b900-59a482305c46@github.com>

On Tue, 7 Nov 2023 00:37:47 GMT, Phil Race <prr at openjdk.org> wrote:

> > > So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac,
> > > but only 35-40ms of that is attributable to the specific needs of layout.
> > 
> > 
> > That looks unfortunate. I guess if we will start to use ffm in other places we can easily spend of 1 second budget on startup=(
> 
> Yes, this case is sufficiently uncommon, that it is OK, and is a decent way to help us track improvements to FFM. But it would be another matter to have to do it for however many of our core software loops and AWT window manager interaction calls we need to get running for a minimal app.
> 
> > > layoutCnt=16000 total=193ms <<< app fully displayed
> > > vs
> > > layoutCnt=16000 total=453ms <<< app fully displayed
> > 
> > 
> > It looks strange that 16000 calls are not enough to warmup, and the difference is so large.
> 
> I am not a C2 expert, (not even an amateur), I just assume that it takes a lot of calls to be fully optimized.

@JornVernee this looks suspicious and seems unrelated to the cold startup issues we discussed before.

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1813640596

From jwaters at openjdk.org  Thu Nov 16 02:08:49 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 16 Nov 2023 02:08:49 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v26]
In-Reply-To: <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
Message-ID: <4XtsPdwNattIdWDDPwNFl5uWX_GDIoVQurOK8_gp5hE=.12c78269-70d1-4a2e-9b9b-d62c8abe359d@github.com>

On Fri, 10 Nov 2023 10:17:30 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment awt_DnDDS.cpp

I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response:

> Back in JDK 8 when we used Visual Studio 2010, we used to not ship
> msvcp*.dll. This changed when I added support for building with Visual
> Studio 2013 [1] in JDK 9. In the patch for that bug I found this text:
> 
> +    # If building with Visual Studio 2010, we can still use
> _STATIC_CPPLIB to
> +    # avoid bundling msvcpNNN.dll. Doesn't work with newer versions of
> visual
> +    # studio.
> 
> So since we switched to Visual Studio 2013, we started to bundle
> msvcp*.dll. It was only ever possible to not bundle it if you built with
> Visual Studio 2010 (or older I suppose). It's pretty safe to say that
> the current mainline JDK build requires msvcp.dll to be bundled. Looking
> at the configure logic, configure will fail unless we find it and the
> copying in open/make/modules/java.base/Copy.gmk is unconditional.
> 
> /Erik
> 
> [1] https://bugs.openjdk.org/browse/JDK-8042707

This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1813660372

From duke at openjdk.org  Thu Nov 16 02:21:40 2023
From: duke at openjdk.org (duke)
Date: Thu, 16 Nov 2023 02:21:40 GMT
Subject: Withdrawn: 8315584 : java/awt/print/Dialog/DialogType.java fails with
 option not  supported: yesno
In-Reply-To: <XHjRSROnXsISeMx2WVT4zpCXl3pW6grgm7nM1rO7pbQ=.cc1ad92b-c776-4b0c-b9ae-e3ac97748b9d@github.com>
References: <XHjRSROnXsISeMx2WVT4zpCXl3pW6grgm7nM1rO7pbQ=.cc1ad92b-c776-4b0c-b9ae-e3ac97748b9d@github.com>
Message-ID: <XkLJVQUbfwNpHiwaNOblD8D7KEEq0kFTPYOVatilBKQ=.54a9e943-b016-479b-a33d-3aaed623dd3e@github.com>

On Sun, 3 Sep 2023 22:12:49 GMT, lawrence.andrews <duke at openjdk.org> wrote:

> Test was failing with "test result: Error. Parse Exception: Arguments to `manual' option not supported: yesno"
> Following are fixed 
> 1) Removed yesno 
> 2) Used PassFailJFrame manual test framework to show the test instruction & allow the user to decide test execution result.
> 3) Added SkippedException in case Printer is not configured on the test host.
> 4) Updated the instruction how to close the print dialog that test is showing to the user.
> 5) Added an extra line to the file that was missing.

This pull request has been closed without being integrated.

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

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

From prr at openjdk.org  Thu Nov 16 03:47:46 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Nov 2023 03:47:46 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v26]
In-Reply-To: <4XtsPdwNattIdWDDPwNFl5uWX_GDIoVQurOK8_gp5hE=.12c78269-70d1-4a2e-9b9b-d62c8abe359d@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
 <4XtsPdwNattIdWDDPwNFl5uWX_GDIoVQurOK8_gp5hE=.12c78269-70d1-4a2e-9b9b-d62c8abe359d@github.com>
Message-ID: <voQ_w619MYdQuwAhh67ohAOnRTBlkTw-wQrU4o6cfSI=.beaffa91-a232-422d-a8e1-45698f2a9a21@github.com>

On Thu, 16 Nov 2023 02:05:29 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response:

Yes, I saw that. It doesn't make any difference.
Although BTW the comment points out we shouldn't be doing static linking anymore.


> This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such

seems unrelated, yes, but I'd have to look at that, to see if there's a reason to touch it. Itchy fingers are  not a valid reason.

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1813744177

From prr at openjdk.org  Thu Nov 16 04:36:36 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Nov 2023 04:36:36 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <ohhR9XAdmwUmUXNf5Wfy2mrzdMOpAuddjzyqxYyFpZ4=.08df2b77-72ec-4a99-ae73-cd5c995b0f94@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <ohhR9XAdmwUmUXNf5Wfy2mrzdMOpAuddjzyqxYyFpZ4=.08df2b77-72ec-4a99-ae73-cd5c995b0f94@github.com>
Message-ID: <wnFrSDZ-_mIPfJrC2e7fxWacEGtP_yB9ZpGaJewYQ_g=.ab96638d-2494-4e27-a965-d55dcd24a3d3@github.com>

On Wed, 15 Nov 2023 15:52:43 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indentation
>
> src/java.desktop/share/classes/sun/font/HBShaper.java line 142:
> 
>> 140:     private static final MemorySegment get_contour_pt_stub;
>> 141: 
>> 142:     private static final MemorySegment store_layout_results_stub;
> 
> I see this Upcall is named `store_layout_results` in case of FFM and we call it similar function in JNI case as `storeGVData`. If we can find some common name and use it will be beneficial in future when we want to compare code between FFM and JNI implementation.

noted, but not something I intend to change here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395138283

From abhiscxk at openjdk.org  Thu Nov 16 05:19:43 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 16 Nov 2023 05:19:43 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

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

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16674/files
  - new: https://git.openjdk.org/jdk/pull/16674/files/846c5de1..f0f4c969

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

  Stats: 24 lines in 1 file changed: 12 ins; 11 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16674/head:pull/16674

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

From abhiscxk at openjdk.org  Thu Nov 16 05:19:46 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 16 Nov 2023 05:19:46 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <GVM9j4TqcBEcX5-G-YsV3AFu41_Bel8Ilb-epLq5k_0=.9ac66d68-75cc-4ed2-8bf2-4e06f23fd462@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <GVM9j4TqcBEcX5-G-YsV3AFu41_Bel8Ilb-epLq5k_0=.9ac66d68-75cc-4ed2-8bf2-4e06f23fd462@github.com>
Message-ID: <7X7jAl_s-2jWdDzpLdj1eFdEg7Ex5H0yfpWZFtozWwQ=.63daa618-e2d2-418a-be85-eae9ce0f153b@github.com>

On Wed, 15 Nov 2023 18:40:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 46:
> 
>> 44:  * @run main TestFileChooserSingleDirectorySelection
>> 45:  */
>> 46: 
> 
> I don't know why it was necessary to move all around all the above lines.
> And whilst import java.io sorts after java.awt, it is long standing convention that the "core"
> packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones. This is true of product source as well as tests.
> So you should just undo all of the above except for adding the new bug id.

Updated.

> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 66:
> 
>> 64:             // create test directory
>> 65:             String tmpDir = System.getProperty("user.home");
>> 66: 
> 
> Does this test HAVE to use the home dir to create the temporary folders and files ?
> Is there some reason some part of the test absolutely requires the home directory ?
> It isn't obvious to me.
> Why can't you instead use  System.getProperty("java.io.tmpdir");

There is no need to have the `home dir` to create the temporary folders and files. Since I was testing in my local mahine to create temp folders in home directory, I kept it as it is.

Changed `home dir` to `java.io.tmpdir` for creating temporary folders and files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1395158783
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1395160301

From psadhukhan at openjdk.org  Thu Nov 16 06:52:35 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Nov 2023 06:52:35 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <ovU11PYqd7tTkGWslJ6ivzGmABWBqa_Lr9I-nyGuMHI=.4f40d3bd-f7c4-40fb-9689-a5193c7af938@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
 <ovU11PYqd7tTkGWslJ6ivzGmABWBqa_Lr9I-nyGuMHI=.4f40d3bd-f7c4-40fb-9689-a5193c7af938@github.com>
Message-ID: <08zM7A5ejZjZ4PNbuoMP6BuDWV68ozLme9ldQ2YU5EM=.3b99d738-eecc-4a6d-a4b3-21031d1aa1b4@github.com>

On Wed, 15 Nov 2023 23:34:04 GMT, Phil Race <prr at openjdk.org> wrote:

> Can someone attach somewhere a clear "with methods" vs "without methods" (ie before and after, side-by side screenshot) of what is considered to be the most problematic consequence of removing them ?

One example of consequence of removing the methods is as Alexey pointed out `the scrollbar becomes flexible along its secondary axis too`
 so `second scrollbar starts growing only after the the third one reaches its minimum size`
That is running Alexey's testcase, if we start to shrink the Frame horizontally, then the 3rd (from left) vertical scrollbar starts to shrink but after a certain point, the 2nd vertical scrollbar starts growing as can be seen on **left side (without methods)** whereas it should remain fixed, as can be seen on **right side (with methods)**
![scroll-resize-shrink](https://github.com/openjdk/jdk/assets/43534309/290e5603-7d8e-4d14-b2d6-6b7721da86bd)

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1813879504

From serb at openjdk.org  Thu Nov 16 06:53:33 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 16 Nov 2023 06:53:33 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
In-Reply-To: <6BikBxrPnwWw-8COtSImapKoXK9eEt6jz3xKAnVtfvk=.9ad1aac8-c9c1-423e-a539-bad4e9839174@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <BwvctAcFS0lydNNJwqQAy5E17XlhEVRtunISD8io25M=.93a56b10-2bcc-41d1-bbcc-27f46a0282ed@github.com>
 <6BikBxrPnwWw-8COtSImapKoXK9eEt6jz3xKAnVtfvk=.9ad1aac8-c9c1-423e-a539-bad4e9839174@github.com>
Message-ID: <xcgorBsgsbKAyqJayux-6Hp7BJ7Md_kWr2oxtyuvIXY=.6402ef75-2e6a-4dcf-953a-8a090f78125f@github.com>

On Tue, 14 Nov 2023 07:06:45 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 79:
>> 
>>> 77: 
>>> 78:                 BufferedImage borderPaintedImg =
>>> 79:                         robot.createScreenCapture(new Rectangle(pt.x, pt.y,
>> 
>> I think the test can be simplified by rendering the progress bar into the buffered image directly.
>
> I couldn't understand. Can you please explain a bit more?

It is not necessary to add the progress bar to the frame and then capture the pixels by the robot. you can render content of the progress bar directly to the BufferedImage.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1395222765

From psadhukhan at openjdk.org  Thu Nov 16 07:01:43 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Nov 2023 07:01:43 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v2]
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <1zVJCQbeUgaFqSDHf7MJZhbA6i7qK45W435DqKSXR1o=.6a4cb7e2-df66-4da9-8723-297c13ae0cb9@github.com>

> CSSBackgroundImage.equals() is implemented

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

  Use Objects.hashCode and add bugid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16613/files
  - new: https://git.openjdk.org/jdk/pull/16613/files/d0d90aeb..b6de4b9e

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

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

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

From psadhukhan at openjdk.org  Thu Nov 16 07:04:43 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Nov 2023 07:04:43 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v3]
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <M01PZodx1Zxvf8WYn1PRYKMrjlQ0dyA2Ngn0T0xY09c=.0dfa0bc3-bc31-44f7-96c2-2fb8897b001a@github.com>

> CSSBackgroundImage.equals() is implemented

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

  Use Objects.hashCode and add bugid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16613/files
  - new: https://git.openjdk.org/jdk/pull/16613/files/b6de4b9e..c656e9ae

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

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

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

From aturbanov at openjdk.org  Thu Nov 16 10:22:39 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Nov 2023 10:22:39 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v3]
In-Reply-To: <AutD3_uBAZqA_rkTbjEYMygL7YL4WIk_G-WBcEzuNmQ=.2f769f9f-4902-4ca1-af98-2ceee3bb7f8c@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
 <AutD3_uBAZqA_rkTbjEYMygL7YL4WIk_G-WBcEzuNmQ=.2f769f9f-4902-4ca1-af98-2ceee3bb7f8c@github.com>
Message-ID: <rBZZH9vLneMgFVE75lyBF77eFryP0jP8acFQIlzvQng=.65cb29fd-f348-46dc-8691-40368b44c0b6@github.com>

On Fri, 10 Nov 2023 21:12:16 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Objects.hashCode and add bugid
>
> src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2971:
> 
>> 2969:         @Override
>> 2970:         public int hashCode() {
>> 2971:             return (this.svalue != null) ? this.svalue.hashCode() : 0;
> 
> This change look fine, but this line can be simplified by the Objects.hashCode();

@prsadhuk idea was to replace whole expression with `Objects.hashCode` (it allows nulls).
Current code looks confusing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16613#discussion_r1395471343

From aturbanov at openjdk.org  Thu Nov 16 10:22:36 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Nov 2023 10:22:36 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v3]
In-Reply-To: <M01PZodx1Zxvf8WYn1PRYKMrjlQ0dyA2Ngn0T0xY09c=.0dfa0bc3-bc31-44f7-96c2-2fb8897b001a@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
 <M01PZodx1Zxvf8WYn1PRYKMrjlQ0dyA2Ngn0T0xY09c=.0dfa0bc3-bc31-44f7-96c2-2fb8897b001a@github.com>
Message-ID: <1kMnHvf6hRDKiXkpeTOxS8hv-_OqrY-0RGzN6RLkwUE=.dc844fd9-fc29-4815-a44c-a16f78c75527@github.com>

On Thu, 16 Nov 2023 07:04:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> CSSBackgroundImage.equals() is implemented
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Objects.hashCode and add bugid

Use Objects.hashCode without explicit null check.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2971:

> 2969:         @Override
> 2970:         public int hashCode() {
> 2971:             return (this.svalue != null) ? Objects.hashCode(this.svalue) : 0;

Simplify:
Suggestion:

            return Objects.hashCode(this.svalue);

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

Changes requested by aturbanov (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16613#pullrequestreview-1734018859
PR Review Comment: https://git.openjdk.org/jdk/pull/16613#discussion_r1395472638

From psadhukhan at openjdk.org  Thu Nov 16 10:51:48 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Nov 2023 10:51:48 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v4]
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <cuwrXADUYAFdWqI18K_rtZ5zzdS7oKuc4msC--BRg44=.5e83aef0-1759-49c6-9e5c-8631daa0b4d5@github.com>

> CSSBackgroundImage.equals() is implemented

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

  Use Objects.hashCode

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16613/files
  - new: https://git.openjdk.org/jdk/pull/16613/files/c656e9ae..22dbc7d0

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

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

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

From aivanov at openjdk.org  Thu Nov 16 11:15:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Nov 2023 11:15:33 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v4]
In-Reply-To: <cuwrXADUYAFdWqI18K_rtZ5zzdS7oKuc4msC--BRg44=.5e83aef0-1759-49c6-9e5c-8631daa0b4d5@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
 <cuwrXADUYAFdWqI18K_rtZ5zzdS7oKuc4msC--BRg44=.5e83aef0-1759-49c6-9e5c-8631daa0b4d5@github.com>
Message-ID: <tGM2lTBAeghNLZUU_Kr-wf1kth8BQvKSZKlwpi-8HDg=.d83e80f7-758b-4f72-bc02-1b2c57ab7294@github.com>

On Thu, 16 Nov 2023 10:51:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> CSSBackgroundImage.equals() is implemented
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Objects.hashCode

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2971:

> 2969:         @Override
> 2970:         public int hashCode() {
> 2971:             return Objects.hashCode(this.svalue);

Suggestion:

            return Objects.hashCode(svalue);

Using `this` is also redundant.

src/java.desktop/share/classes/javax/swing/text/html/CSS.java line 2977:

> 2975:         public boolean equals(Object val) {
> 2976:             return val instanceof CSS.BackgroundImage img
> 2977:                    && Objects.equals(this.svalue, img.svalue);

Suggestion:

            return val instanceof CSS.BackgroundImage img
                   && Objects.equals(svalue, img.svalue);

Using `this` is redundant. You didn't use it in other implementations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16613#discussion_r1395537150
PR Review Comment: https://git.openjdk.org/jdk/pull/16613#discussion_r1395538260

From psadhukhan at openjdk.org  Thu Nov 16 11:25:47 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 16 Nov 2023 11:25:47 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v5]
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <4cMXW5_XX7ofsNgciM2rLJD8JoaLiGuUyIOqeUVoSnc=.7e1d3fdb-1ddf-4a23-aadb-fc98c6d40a3a@github.com>

> CSSBackgroundImage.equals() is implemented

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

  Remove this reference

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16613/files
  - new: https://git.openjdk.org/jdk/pull/16613/files/22dbc7d0..b296fea2

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

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

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

From aivanov at openjdk.org  Thu Nov 16 11:52:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Nov 2023 11:52:33 GMT
Subject: RFR: 8318113: CSS.BackgroundImage doesn't implement equals [v5]
In-Reply-To: <4cMXW5_XX7ofsNgciM2rLJD8JoaLiGuUyIOqeUVoSnc=.7e1d3fdb-1ddf-4a23-aadb-fc98c6d40a3a@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
 <4cMXW5_XX7ofsNgciM2rLJD8JoaLiGuUyIOqeUVoSnc=.7e1d3fdb-1ddf-4a23-aadb-fc98c6d40a3a@github.com>
Message-ID: <djQfSpeMXszFezgruGXHENq2pdC2qvz3JMpP8HmjOQg=.e80cbbb9-c8fe-4d6c-846a-1c044b974206@github.com>

On Thu, 16 Nov 2023 11:25:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> CSSBackgroundImage.equals() is implemented
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove this reference

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16613#pullrequestreview-1734185433

From aivanov at openjdk.org  Thu Nov 16 11:52:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Nov 2023 11:52:38 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <8QYgZkm4uRVP_c40piBzUE0uFL4daCsbZfr7tiS5uYc=.f4797657-d827-48dd-a9dc-c60f7fa1db75@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

> > Can someone attach somewhere a clear "with methods" vs "without methods" (ie before and after, side-by side screenshot) of what is considered to be the most problematic consequence of removing them ?
> 
> One example of consequence of removing the methods is as Alexey pointed out `the scrollbar becomes flexible along its secondary axis too` so `second scrollbar starts growing only after the the third one reaches its minimum size`....Not sure if it will considered a bug if we remove the methods but it's a departure from existing behaviour... That is running Alexey's testcase, if we start to shrink the Frame horizontally, then the 3rd (from left) vertical scrollbar starts to shrink but after a certain point, the 2nd vertical scrollbar starts growing as can be seen on **left side (without methods)** whereas it should remain fixed, as can be seen on **right side (with methods)** ![scroll-resize-shrink](https://user-images.githubusercontent.com/43534309/283344574-290e5603-7d8e-4d14-b2d6-6b7721da86bd.png)

In short:

* the scroll bars are currently **rigid** along their secondary axis, they stay at their preferred size. Their widths (referring to Prasanta's case discussing the vertical scroll bars) are never less than their preferred size which is equal to the minimum and maximum size.  
Thus, the left panel with the vertical scroll bars gets clipped if the frame becomes too small, it's clearly seen on the right image above: the right cyan border isn't seen any more.
* with the removed `getMinimumSize` and `getMaximumSize` implementation, the scroll bars become **flexible** along their secondary axis. What we see is natural:
    * The layout manager gives components the preferred size, therefore the two scroll bars on the left remain at their preferred size, and the third vertical scroll bar shrinks as the frame width shrinks.
    * Once the third vertical scroll bar reaches its minimum size, it can't shrink any more, therefore the layout manager makes the second scroll bar larger, it can do so because its maximum size is larger than its preferred size.
        * The second scroll bar grows until it reaches its maximum width. After this point, the layout manager cannot satisfy the minimum widths of all the scroll bars, and the left panel becomes clipped, the part of the third scroll bar disappears.

All the above is the result of differences in the returned minimum and maximum sizes: *rigid* versus *flexible*.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1814292403

From aivanov at openjdk.org  Thu Nov 16 12:25:30 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Nov 2023 12:25:30 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
In-Reply-To: <xcgorBsgsbKAyqJayux-6Hp7BJ7Md_kWr2oxtyuvIXY=.6402ef75-2e6a-4dcf-953a-8a090f78125f@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <BwvctAcFS0lydNNJwqQAy5E17XlhEVRtunISD8io25M=.93a56b10-2bcc-41d1-bbcc-27f46a0282ed@github.com>
 <6BikBxrPnwWw-8COtSImapKoXK9eEt6jz3xKAnVtfvk=.9ad1aac8-c9c1-423e-a539-bad4e9839174@github.com>
 <xcgorBsgsbKAyqJayux-6Hp7BJ7Md_kWr2oxtyuvIXY=.6402ef75-2e6a-4dcf-953a-8a090f78125f@github.com>
Message-ID: <9zUcuqrgstnZKTt2MVAh26PThpgHpgyeBfAr2rEr_mk=.7dd766c4-796d-4e1e-bbcc-959051aa182c@github.com>

On Thu, 16 Nov 2023 06:50:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I couldn't understand. Can you please explain a bit more?
>
> It is not necessary to add the progress bar to the frame and then capture the pixels by the robot. you can render content of the progress bar directly to the BufferedImage.

There are a number of tests which do this, scaled borders are those that come to my mind first:

https://github.com/openjdk/jdk/blob/1d9688667e667dc710d64e52f1e918e047beaca3/test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java#L300-L311

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1395615748

From aivanov at openjdk.org  Thu Nov 16 12:31:29 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Nov 2023 12:31:29 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
In-Reply-To: <9zUcuqrgstnZKTt2MVAh26PThpgHpgyeBfAr2rEr_mk=.7dd766c4-796d-4e1e-bbcc-959051aa182c@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <BwvctAcFS0lydNNJwqQAy5E17XlhEVRtunISD8io25M=.93a56b10-2bcc-41d1-bbcc-27f46a0282ed@github.com>
 <6BikBxrPnwWw-8COtSImapKoXK9eEt6jz3xKAnVtfvk=.9ad1aac8-c9c1-423e-a539-bad4e9839174@github.com>
 <xcgorBsgsbKAyqJayux-6Hp7BJ7Md_kWr2oxtyuvIXY=.6402ef75-2e6a-4dcf-953a-8a090f78125f@github.com>
 <9zUcuqrgstnZKTt2MVAh26PThpgHpgyeBfAr2rEr_mk=.7dd766c4-796d-4e1e-bbcc-959051aa182c@github.com>
Message-ID: <GOlIAbt0V36k3Yju1jKrAEgZcD3B_BdyhFRuSqpietc=.6d574d8d-3844-4917-9fd0-f17af9e7dc31@github.com>

On Thu, 16 Nov 2023 12:23:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It is not necessary to add the progress bar to the frame and then capture the pixels by the robot. you can render content of the progress bar directly to the BufferedImage.
>
> There are a number of tests which do this, scaled borders are those that come to my mind first:
> 
> https://github.com/openjdk/jdk/blob/1d9688667e667dc710d64e52f1e918e047beaca3/test/jdk/javax/swing/border/EtchedBorder/ScaledEtchedBorderTest.java#L300-L311

Another example:

https://github.com/openjdk/jdk/blob/b7425b63f6b69ba8709664377b4e037176ab6139/test/jdk/javax/swing/text/FlowView/6318524/bug6318524.java#L176-L185

Here `textPane` component is painted to the `BufferedImage`. Use the image to analyse rendering.

(In many cases, such a test can run *headless*.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1395621776

From aivanov at openjdk.org  Thu Nov 16 13:16:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Nov 2023 13:16:34 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <JVHf4whxLHnga9ANnEWcJi0vPlZRqCk0kTSk88lnqIQ=.bacacec0-1463-4a88-b155-302ddf4bb4e1@github.com>

On Thu, 2 Nov 2023 04:13:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 29:

> 27:  * @key headful
> 28:  * @summary Verifies if JProgressBar border is painted even though border
> 29:  *          painting is set to false

Suggestion:

 * @summary Verifies JProgressBar border is not painted when border
 *          painting is set to false

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 63:

> 61:             } else {
> 62:                 continue;
> 63:             }

I suggest inverting the condition to skip other L&Fs:
Suggestion:

            if (!laf.getName().contains("Nimbus") && !laf.getName().contains("GTK")) {
                continue;
            }

            System.out.println("Testing LAF: " + laf.getName());
            SwingUtilities.invokeAndWait(() -> setLookAndFeel(laf));

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 145:

> 143:     */
> 144: 
> 145:     private static boolean compareImage(BufferedImage img1, BufferedImage img2) {

You can use the method from `regtesthelpers/Util`:

https://github.com/openjdk/jdk/blob/9faead1469481e268b451f2853c8fec8613426b9/test/jdk/javax/swing/regtesthelpers/Util.java#L59-L80

If you don't want to use, I suggest reversing the conditions so that `compareImage` returns `true` when images are the same ? it's more common and therefore less confusing. In addition to that, return quickly if the sizes are different (can they ever be?) and avoid nesting the `for`-loops inside the `if` statement.

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

PR Review: https://git.openjdk.org/jdk/pull/16467#pullrequestreview-1734324288
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1395663025
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1395666368
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1395673238

From azvegint at openjdk.org  Thu Nov 16 15:02:51 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 16 Nov 2023 15:02:51 GMT
Subject: Integrated: 8319103: Popups that request focus are not shown on Linux
 with Wayland
In-Reply-To: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
References: <fbSzgnlpuR7XHQ4nrH-8Hb2nqjJDUGBk460VeH3sH5o=.ba470e18-b93a-4ebf-9755-0b3c419eb8da@github.com>
Message-ID: <Kq7_jVLzKypaO-Nwk2jr4YNfK28TGnvOLdhWvS9pm6M=.a6048cda-490c-415c-8738-d38a262e16eb@github.com>

On Mon, 13 Nov 2023 17:30:17 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> This is the fix for the regression introduced in [JDK-8280993](https://bugs.openjdk.org/browse/JDK-8280993).
> 
> That fix was to dismiss a popup if the owner loses the window focus when running in Wayland, and didn't take into account that the popup itself can be focusable.
> 
> This fix closes the popup only if the focus moves away from the calling window and the popup itself.
> 
> There is no jtreg test provided because it requires transferring the window focus to a non-X11 window, and our current robot implementation [does not allow this](https://bugs.openjdk.org/browse/JDK-8280983).

This pull request has now been integrated.

Changeset: f3ed2758
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3ed27582e16c3a323f590863cbeec6d35e20b58
Stats:     128 lines in 2 files changed: 121 ins; 5 del; 2 mod

8319103: Popups that request focus are not shown on Linux with Wayland

Reviewed-by: serb, prr

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

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

From kizune at openjdk.org  Thu Nov 16 17:31:48 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 16 Nov 2023 17:31:48 GMT
Subject: RFR: 8283214: [macos] Screen magnifier does not show the magnified
 text for JcomboBox [v12]
In-Reply-To: <190JP0hYXltMoY_EBQg8hsitiUvtvQIj5wM2Zy8C6OY=.75e827bb-4a3d-4d82-ba8d-09ff26e852d8@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
 <190JP0hYXltMoY_EBQg8hsitiUvtvQIj5wM2Zy8C6OY=.75e827bb-4a3d-4d82-ba8d-09ff26e852d8@github.com>
Message-ID: <snvLmpnvPilD8L2xG3dfvhLDwAUQnRxmZhq_H_zuhMU=.d4be19ec-1db7-4fac-8a3a-af19e92447bb@github.com>

On Fri, 10 Nov 2023 18:20:27 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
>> 
>> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
>> 
>> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Condition combined

Marked as reviewed by kizune (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14497#pullrequestreview-1735053303

From aivanov at openjdk.org  Thu Nov 16 18:27:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 16 Nov 2023 18:27:35 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode
 on different keyboard layouts
In-Reply-To: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
Message-ID: <kSSGyw3_Dyx3zcceRFIQ1ekh_6xC5m0Z8hZfoglgPy0=.4ebba018-b261-44ef-becb-e2c216dd9cba@github.com>

On Tue, 14 Nov 2023 21:22:37 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updated previous fix (8262945) to work on extendedKeyCodes. Updated AcceleratorTest to use PassFailJFrame instead of Applet

I can't still make the test pass on macOS Ventura (13.5.2), yet the fix did improve the situation. Previously, fewer keystrokes led to *Fired* being printed.

The cases 2 and 5 do not work for me. I use a PC layout for Russian on Mac, period in this Russian layout is on "/?" key but pressing Ctrl+(/?) doesn't fires the event. Nor is the event fired when I press Alt+? (key with ".>").

The fix has resolved the issue with Ctrl+N: it works with the fix but doesn't without it.

test/jdk/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java line 1:

> 1: /*

Is it possible to print which particular event fired? It could be useful for debugging.

I'd create a list of `Action`s with the names and shortcuts (as a KeyStroke and as string for printing) and then print each action name with corresponding shortcut. Or create a list of objects with corresponding data. I didn't think it through.

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

PR Review: https://git.openjdk.org/jdk/pull/16664#pullrequestreview-1735155100
PR Review Comment: https://git.openjdk.org/jdk/pull/16664#discussion_r1396161438

From prr at openjdk.org  Thu Nov 16 19:10:39 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Nov 2023 19:10:39 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v5]
In-Reply-To: <nWuQnby5zX6jhBN1JYULcLryeHYVAgP5_468kOLUmuM=.dc2da099-aa7e-42fd-a08f-b7959484e222@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <nWuQnby5zX6jhBN1JYULcLryeHYVAgP5_468kOLUmuM=.dc2da099-aa7e-42fd-a08f-b7959484e222@github.com>
Message-ID: <6O37UmWBrOZHUV_Ev1qRxILYS60tQ4UPNkbr5rv4hbQ=.a204a6b6-9d10-46e8-9947-1fa96c656fae@github.com>

On Wed, 15 Nov 2023 16:26:56 GMT, Alec Su <duke at openjdk.org> wrote:

>> JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.
>> 
>> The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.
>> 
>> 
>> import javax.sound.midi.*;
>> 
>> public class MidiTest {
>>     public static class RawMidiMessage extends MidiMessage {
>>         public RawMidiMessage(byte[] data) {
>>             super(data);
>>         }
>> 
>>         @Override
>>         public Object clone() {
>>             return new RawMidiMessage(this.getMessage());
>>         }
>>     }
>> 
>>     public static void main(String[] args) {
>>         var deviceInfos = MidiSystem.getMidiDeviceInfo();
>>         for (var info : deviceInfos) {
>>             try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
>>                 if (device.getMaxReceivers() != 0) {
>>                     System.out.println("Open MIDI port: " + info.getName());
>>                     device.open();
>>                     Receiver receiver = device.getReceiver();
>>                     // Send two sysex messages at once
>>                     receiver.send(new RawMidiMessage(new byte[]{
>>                             (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
>>                             (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
>>                         }), -1);
>>                     // Send another sysex message
>>                     receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
>>                 }
>>             } catch (MidiUnavailableException e) {
>>                 e.printStackTrace();
>>             }
>>         }
>>     }
>> }
>> 
>> 
>> The expected messages received should be the following three messages
>> 
>> F0 7D 01 F7
>> F0 7D 02 F7
>> F0 7D 03 F7
>> 
>> 
>> But acually four messages was received with the second message repeated twice.
>> 
>> F0 7D 01 F7
>> F0 7D 02 F7
>> F0 7D 03 F7
>> F0 7D 02 F7
>> 
>> 
>> To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buf...
>
> Alec Su 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:
> 
>  - Remove the testcase and reuse the testcase added in #16477
>  - Merge branch 'master' into sysex-win
>  - Remove OS check in the test
>  - Code cleanup
>  - Add a testcase for the buffer issue on Windows
>  - Resolve the message size issue when sending SysexMessage on Windows

I ran this change through our CI testing system and it all looks good.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16399#pullrequestreview-1735250581

From achung at openjdk.org  Thu Nov 16 19:12:34 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 16 Nov 2023 19:12:34 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v4]
In-Reply-To: <XW1JMlBS-NCW_yWgSVTJbJBbJtT_cEAOFlWAK9sL1bI=.ae3d9a68-753a-4438-85bb-f7f6ef6ba54a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <LUZ0alzQIQIjwMppiucY2kmKe1tRxpB6oLVUSIXDKcw=.bc5558a3-41f2-4557-b9dc-c58ff2e232a8@github.com>
 <XW1JMlBS-NCW_yWgSVTJbJBbJtT_cEAOFlWAK9sL1bI=.ae3d9a68-753a-4438-85bb-f7f6ef6ba54a@github.com>
Message-ID: <AdayEi5Y-2tz6h19hBrZZVbSwoF9OMbfRJ1gLkTCnu0=.c726f344-d0c9-47bc-8f10-afb621ae2aa8@github.com>

On Wed, 15 Nov 2023 19:11:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 603:
> 
>> 601:             }
>> 602:         } else {
>> 603:             for(int row = rMin; row <= rMax; row++) {
> 
> Suggestion:
> 
>             for (int row = rMin; row <= rMax; row++) {

it's just a spacing thing, but should these be left alone since they weren't changed with the fix?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1396208966

From prr at openjdk.org  Thu Nov 16 19:32:52 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Nov 2023 19:32:52 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v5]
In-Reply-To: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
Message-ID: <B_fpS2jYJK-7g_1rIIQVx941D6CRE3EF7UUt_tAnMys=.9a3376cb-a2b4-4acd-aa8e-6f3cc5125020@github.com>

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

Phil Race has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge remote-tracking branch 'upstream/master' into harfbuzz_panama
   Merge
 - indentation
 - Use new arrayElementVarHandle method
 - Merge remote-tracking branch 'upstream/master' into harfbuzz_panama
   Merge
 - remove tailing white space
 - use scaling
 - Fix windows build, remove perf. logging
 - Add test, fix bug
 - use allocateFrom
 - add offset param
 - ... and 11 more: https://git.openjdk.org/jdk/compare/9727f4bd...f6f2abf2

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

Changes: https://git.openjdk.org/jdk/pull/15476/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15476&range=04
  Stats: 1371 lines in 7 files changed: 1369 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15476.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15476/head:pull/15476

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

From jvernee at openjdk.org  Thu Nov 16 19:38:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Nov 2023 19:38:35 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <afyI8LrW67diDlYLn96A7PmjPHH8P8uU6MYhBNWbDek=.c5a97263-0660-42af-b900-59a482305c46@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
 <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>
 <evGDJiD-l_-ZWqXrr_49mipBrBBq-bOT4AIw0ZvZziY=.6945f131-afc1-47b6-8f3f-edbe3362fb3b@github.com>
 <0NrUdOATwm9ckjU4JesHN7RnvxUtHm7ugDpJ1GAanUA=.63031f7a-1d91-477d-ac64-63a830c2fba6@github.com>
 <afyI8LrW67diDlYLn96A7PmjPHH8P8uU6MYhBNWbDek=.c5a97263-0660-42af-b900-59a482305c46@github.com>
Message-ID: <nUEFJXDkcde_fVxWEJgzs3ZmKwwknT0fneJM3ZyVekA=.fa4abd92-1533-4d3c-b31d-60b25497861b@github.com>

On Thu, 16 Nov 2023 01:54:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > > So we have somewhere around a fixed 125ms startup cost for the FFM case - as measured on my Mac,
> > > > but only 35-40ms of that is attributable to the specific needs of layout.
> > > 
> > > 
> > > That looks unfortunate. I guess if we will start to use ffm in other places we can easily spend of 1 second budget on startup=(
> > 
> > 
> > Yes, this case is sufficiently uncommon, that it is OK, and is a decent way to help us track improvements to FFM. But it would be another matter to have to do it for however many of our core software loops and AWT window manager interaction calls we need to get running for a minimal app.
> > > > layoutCnt=16000 total=193ms <<< app fully displayed
> > > > vs
> > > > layoutCnt=16000 total=453ms <<< app fully displayed
> > > 
> > > 
> > > It looks strange that 16000 calls are not enough to warmup, and the difference is so large.
> > 
> > 
> > I am not a C2 expert, (not even an amateur), I just assume that it takes a lot of calls to be fully optimized.
> 
> @JornVernee this looks suspicious and seems unrelated to the cold startup issues we discussed before.

I suspect the benchmark might be measuring the java.lang.foreign code needing to be loaded as part of the benchmark. While for JNI, the initialization of all the JNI machinery is included in the startup of the application. Was the running time of the entire application/process measured? Or only from the start of the `main` method?

Secondly, we have not spent a lot of time optimizing the startup performance of FFM yet. There are things we could do such as pre-generating classes during jlink-time, similar to what we do for java.lang.invoke/lambda implementation classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1815189946

From prr at openjdk.org  Thu Nov 16 19:59:34 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Nov 2023 19:59:34 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <nUEFJXDkcde_fVxWEJgzs3ZmKwwknT0fneJM3ZyVekA=.fa4abd92-1533-4d3c-b31d-60b25497861b@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
 <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>
 <evGDJiD-l_-ZWqXrr_49mipBrBBq-bOT4AIw0ZvZziY=.6945f131-afc1-47b6-8f3f-edbe3362fb3b@github.com>
 <0NrUdOATwm9ckjU4JesHN7RnvxUtHm7ugDpJ1GAanUA=.63031f7a-1d91-477d-ac64-63a830c2fba6@github.com>
 <afyI8LrW67diDlYLn96A7PmjPHH8P8uU6MYhBNWbDek=.c5a97263-0660-42af-b900-59a482305c46@github.com>
 <nUEFJXDkcde_fVxWEJgzs3ZmKwwknT0fneJM3ZyVekA=.fa4abd92-1533-4d3c-b31d-60b25497861b@github.com>
Message-ID: <Abm7UzdT9W9sRZKHGPt0pG1s_46zkjHd0xvHF0TQ5D8=.a1613234-c122-44b9-ac93-301387577a27@github.com>

On Thu, 16 Nov 2023 19:35:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > > > > layoutCnt=16000 total=193ms <<< app fully displayed
> > > > > vs
> > > > > layoutCnt=16000 total=453ms <<< app fully displayed
> > > > 
> > > > 
> > > > It looks strange that 16000 calls are not enough to warmup, and the difference is so large.
> > > 
> > > 
> > > I am not a C2 expert, (not even an amateur), I just assume that it takes a lot of calls to be fully optimized.
> > 
> > 
> > @JornVernee this looks suspicious and seems unrelated to the cold startup issues we discussed before.
> 
> I suspect the benchmark might be measuring the java.lang.foreign code needing to be loaded as part of the benchmark. While for JNI, the initialization of all the JNI machinery is included in the startup of the application. Was the running time of the entire application/process measured? Or only from the start of the `main` method?

Yes, that's correct, it includes all the startup costs in that number.
So as @jayathirthrao observed, the comment "16000 calls are not enough to warmup" may be slightly off the mark since at this time, each 1,000 FFM calls is already roughly as fast as each 1,000 JNI calls
So we ARE warmed up by then, but I have no idea what would be a normal expectation.
Looking at the numbers above it is roughly around 12,000 that we reach parity for the speed of each incremental call.

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1815221438

From prr at openjdk.org  Thu Nov 16 20:06:52 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Nov 2023 20:06:52 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v6]
In-Reply-To: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
Message-ID: <42m2RsRlTT0TXrJOCadUgDIVjSOCSr-k2YQD4Ow_YhQ=.6a6958a1-b0fe-489f-a9c3-9de6a97ca865@github.com>

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

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

  8318364

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15476/files
  - new: https://git.openjdk.org/jdk/pull/15476/files/f6f2abf2..ee60f7e9

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

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

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

From prr at openjdk.org  Thu Nov 16 20:07:00 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 16 Nov 2023 20:07:00 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <ohhR9XAdmwUmUXNf5Wfy2mrzdMOpAuddjzyqxYyFpZ4=.08df2b77-72ec-4a99-ae73-cd5c995b0f94@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <ohhR9XAdmwUmUXNf5Wfy2mrzdMOpAuddjzyqxYyFpZ4=.08df2b77-72ec-4a99-ae73-cd5c995b0f94@github.com>
Message-ID: <UC0ggxzxvRDSPXelu_4c3IzjFh70GerqJq3khe7_mK0=.c9c94315-4dc8-4766-8c8b-db0c54967eac@github.com>

On Wed, 15 Nov 2023 15:06:55 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indentation
>
> src/java.desktop/share/classes/sun/font/HBShaper.java line 66:
> 
>> 64:      * };
>> 65:      */
>> 66:    private static final UnionLayout VarIntLayout = MemoryLayout.unionLayout(
> 
> Indentation issue.

fixed

> src/java.desktop/share/classes/sun/font/HBShaper.java line 84:
> 
>> 82:      * };
>> 83:      */
>> 84:      private static final StructLayout PositionLayout = MemoryLayout.structLayout(
> 
> Indentation issue.

fixed

> src/java.desktop/share/classes/sun/font/HBShaper.java line 144:
> 
>> 142:     private static final MemorySegment store_layout_results_stub;
>> 143: 
>> 144:    private static FunctionDescriptor
> 
> Indentation issue.

fixed

> src/java.desktop/share/classes/sun/font/HBShaper.java line 153:
> 
>> 151:    }
>> 152: 
>> 153:    private static MethodHandle getMethodHandle
> 
> Indentation issue.

fixed

> src/java.desktop/share/classes/sun/font/HBShaper.java line 165:
> 
>> 163:    }
>> 164: 
>> 165:    static {
> 
> Indentation issue.

fixed

> src/java.desktop/share/classes/sun/font/HBShaper.java line 212:
> 
>> 210:         jdk_hb_shape_handle = tmp4;
>> 211: 
>> 212:         Arena garena = Arena.global(); // creating stubs that exist until VM exit.
> 
> Variable name `gArena`(for global arena) is better than using `garena`.

i'm using lowercase in the other names, so I think it OK

> src/java.desktop/share/classes/sun/font/HBShaper.java line 347:
> 
>> 345:         glyphIDPtr.setAtIndex(JAVA_INT, 0, glyphID);
>> 346:         return (glyphID != 0) ? 1 : 0;
>> 347: }
> 
> Indentation issue.

fixed

> src/java.desktop/share/classes/sun/font/HBShaper.java line 659:
> 
>> 657:         startPt.y = advY;
>> 658:         startPt.x = advX;
>> 659:   }
> 
> Indentation issue.

fixed

> src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 193:
> 
>> 191:         } else {
>> 192:            long pFace = getFacePtr(font);
>> 193:             shape(font, strike, ptSize, mat, pFace,
> 
> Is it okay to not have `(pFace != 0)` check here?

i added back the check

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396267684
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396267831
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396268039
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396268116
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396268358
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396268796
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396269031
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396269300
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1396267142

From jvernee at openjdk.org  Thu Nov 16 20:28:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Nov 2023 20:28:33 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <Abm7UzdT9W9sRZKHGPt0pG1s_46zkjHd0xvHF0TQ5D8=.a1613234-c122-44b9-ac93-301387577a27@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <leNQiQZjaaNeiOygb2x_0llKQf8-c7j8k7bz-jbaygY=.ef2526ae-7ee6-4c1c-bec2-2b67f47282d2@github.com>
 <Q5kLCIIlUt4pkNCVQqm9Y4XbRLKDnfDeEo1vZB75UqM=.9ad852de-7be2-486a-9fd8-88edf5750263@github.com>
 <evGDJiD-l_-ZWqXrr_49mipBrBBq-bOT4AIw0ZvZziY=.6945f131-afc1-47b6-8f3f-edbe3362fb3b@github.com>
 <0NrUdOATwm9ckjU4JesHN7RnvxUtHm7ugDpJ1GAanUA=.63031f7a-1d91-477d-ac64-63a830c2fba6@github.com>
 <afyI8LrW67diDlYLn96A7PmjPHH8P8uU6MYhBNWbDek=.c5a97263-0660-42af-b900-59a482305c46@github.com>
 <nUEFJXDkcde_fVxWEJgzs3ZmKwwknT0fneJM3ZyVekA=.fa4abd92-1533-4d3c-b31d-60b25497861b@github.com>
 <Abm7UzdT9W9sRZKHGPt0pG1s_46zkjHd0xvHF0TQ5D8=.a1613234-c122-44b9-ac93-301387577a27@github.com>
Message-ID: <vfoThGbRiba9QNEkfTiEn51_Hf0iuTrnzrBVmhd7iXM=.b9233f7a-f9b6-49ff-94ab-6a36731acebc@github.com>

On Thu, 16 Nov 2023 19:56:51 GMT, Phil Race <prr at openjdk.org> wrote:

> > > > > > layoutCnt=16000 total=193ms <<< app fully displayed
> > > > > > vs
> > > > > > layoutCnt=16000 total=453ms <<< app fully displayed
> > > > > 
> > > > > 
> > > > > It looks strange that 16000 calls are not enough to warmup, and the difference is so large.
> > > > 
> > > > 
> > > > I am not a C2 expert, (not even an amateur), I just assume that it takes a lot of calls to be fully optimized.
> > > 
> > > 
> > > @JornVernee this looks suspicious and seems unrelated to the cold startup issues we discussed before.
> > 
> > 
> > I suspect the benchmark might be measuring the java.lang.foreign code needing to be loaded as part of the benchmark. While for JNI, the initialization of all the JNI machinery is included in the startup of the application. Was the running time of the entire application/process measured? Or only from the start of the `main` method?
> 
> Yes, that's correct, it includes all the startup costs in that number. So as @jayathirthrao observed, the comment "16000 calls are not enough to warmup" may be slightly off the mark since at this time, each 1,000 FFM calls is already roughly as fast as each 1,000 JNI calls So we ARE warmed up by then, but I have no idea what would be a normal expectation. Looking at the numbers above it is roughly around 12,000 that we reach parity for the speed of each incremental call.

C2/fully optimized compilation kicks in after 10 000 calls, and is asynchronous by default (i.e. the rest of the application keeps running). So, 12,000 sounds relatively normal to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/15476#issuecomment-1815260564

From philip.race at oracle.com  Thu Nov 16 20:30:07 2023
From: philip.race at oracle.com (Philip Race)
Date: Thu, 16 Nov 2023 12:30:07 -0800
Subject: Is it valid to call JComponent#paintImmediately on a non-EDT
 thread (yet)?
In-Reply-To: <CAMTdVeoVr=xzqsMHXeLdZR09G+O8U_AtwTTGS6xPj2PXTheWJw@mail.gmail.com>
References: <CAMTdVeoVr=xzqsMHXeLdZR09G+O8U_AtwTTGS6xPj2PXTheWJw@mail.gmail.com>
Message-ID: <895ab355-9586-4c49-8384-a660ae8483ae@oracle.com>

Because (like in this case), an AWT component might actually be 
implemented using Swing,
the recommendation is to treat AWT components like Swing, and update 
them only on the EDT.

-phil.

On 11/15/23 4:01 PM, Nikita Provotorov wrote:
> Hello!
> I've discovered that on X11 platforms a call 
> of?java.awt.TextComponent#setText can lead to a call 
> of?javax.swing.JComponent#paintImmediately(java.awt.Rectangle) on the 
> same thread.
> Since java.awt.TextComponent#setText is allowed to be called on any 
> thread (because it's AWT, not Swing), JComponent#paintImmediately may 
> be called outside of EDT. Is this a valid behavior?
>
> The following stacktrace shows how exactly this can happen:
>
>     at javax.swing.JComponent.paintImmediately
>     at sun.awt.X11.XTextAreaPeer$AWTTextArea.repaintNow
>     at sun.awt.X11.XTextAreaPeer.repaintText
>     at sun.awt.X11.XTextAreaPeer.setText
>     at java.awt.TextComponent.setText
>
>
> Best regards,
> Nikita Provotorov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231116/c72f1afd/attachment-0001.htm>

From jdv at openjdk.org  Fri Nov 17 04:42:33 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 17 Nov 2023 04:42:33 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v6]
In-Reply-To: <42m2RsRlTT0TXrJOCadUgDIVjSOCSr-k2YQD4Ow_YhQ=.6a6958a1-b0fe-489f-a9c3-9de6a97ca865@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <42m2RsRlTT0TXrJOCadUgDIVjSOCSr-k2YQD4Ow_YhQ=.6a6958a1-b0fe-489f-a9c3-9de6a97ca865@github.com>
Message-ID: <hsKC8HwxDzLZE0EDHjK0G6lv-If98qvkU4Bx_Iv3b_4=.c3f90cd0-a379-49c3-8ffc-a4ef518b6e48@github.com>

On Thu, 16 Nov 2023 20:06:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8318364

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15476#pullrequestreview-1736032879

From jwaters at openjdk.org  Fri Nov 17 07:56:17 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Nov 2023 07:56:17 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v27]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <c_EGzhdA2tio_LxcVeiszNFXrtdGJvFSiHo4Y-KaH_w=.ab6c5fd3-3aa6-407e-8b30-d0477d284d90@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

 - Cleanup order awt_Canvas.cpp
 - Manual way of cleanup in awt_Canvas.cpp :(

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/b7c0002a..9ddccf90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=25-26

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

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

From jwaters at openjdk.org  Fri Nov 17 07:59:47 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Nov 2023 07:59:47 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v26]
In-Reply-To: <voQ_w619MYdQuwAhh67ohAOnRTBlkTw-wQrU4o6cfSI=.beaffa91-a232-422d-a8e1-45698f2a9a21@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
 <4XtsPdwNattIdWDDPwNFl5uWX_GDIoVQurOK8_gp5hE=.12c78269-70d1-4a2e-9b9b-d62c8abe359d@github.com>
 <voQ_w619MYdQuwAhh67ohAOnRTBlkTw-wQrU4o6cfSI=.beaffa91-a232-422d-a8e1-45698f2a9a21@github.com>
Message-ID: <tuRkUKzaIzDzgOw_rCPk8hLE_tKszkqjHHTiiihNfSw=.c7ff982f-1ad5-4665-bf5d-adbbdc61a24b@github.com>

On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race <prr at openjdk.org> wrote:

> > I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response:
> 
> Yes, I saw that. It doesn't make any difference. Although BTW the comment points out we shouldn't be doing static linking anymore.
> 
> > This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such
> 
> seems unrelated, yes, but I'd have to look at that, to see if there's a reason to touch it. Itchy fingers are not a valid reason.

I've converted awt_Canvas.cpp to use manual cleaup, as requested. Are we sure we really want to do this for the rest of the places where goto is an issue and not rely on the C++ Library? There are multiple usages of JNI_CHECK_PEER_GOTO in those areas, and manually expanding the macro in those areas will quickly become very messy

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

PR Comment: https://git.openjdk.org/jdk/pull/15096#issuecomment-1815895692

From jwaters at openjdk.org  Fri Nov 17 08:24:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 17 Nov 2023 08:24:18 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v28]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <ntTXWoJHJ5051MsaEZg9KMGsxyfLWGENoJMH_MNJ28Q=.a22df483-9b34-490c-a8a7-fbe89fcb3a50@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

 - Includes for awt_Component.cpp
 - Likewise for awt_Component.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/9ddccf90..a9dc87f2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=26-27

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

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

From nikita.provotorov at jetbrains.com  Fri Nov 17 10:51:24 2023
From: nikita.provotorov at jetbrains.com (Nikita Provotorov)
Date: Fri, 17 Nov 2023 11:51:24 +0100
Subject: Is it valid to call JComponent#paintImmediately on a non-EDT
 thread (yet)?
In-Reply-To: <895ab355-9586-4c49-8384-a660ae8483ae@oracle.com>
References: <CAMTdVeoVr=xzqsMHXeLdZR09G+O8U_AtwTTGS6xPj2PXTheWJw@mail.gmail.com>
 <895ab355-9586-4c49-8384-a660ae8483ae@oracle.com>
Message-ID: <CAMTdVerbDWuq9s6yzcJYnChbefZGBSj-zJ2mxt7LbgCisK52_A@mail.gmail.com>

Thanks for the response!
However I'd like to clarify: is it correct to say that the current
implementation of sun.awt.X11.XTextAreaPeer#repaintText
<https://github.com/openjdk/jdk/blob/8ec6b8de3bb3d7aeebdcb45d761b18cce3bab75e/src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java#L258>
is
wrong because it doesn't make sure if
*javax.swing.JComponent#paintImmediately* is called on EDT only (e.g. via
*SwingUtilities#invokeLater*)?

Best regards,
Nikita Provotorov


On Thu, Nov 16, 2023 at 9:30?PM Philip Race <philip.race at oracle.com> wrote:

> Because (like in this case), an AWT component might actually be
> implemented using Swing,
> the recommendation is to treat AWT components like Swing, and update them
> only on the EDT.
>
> -phil.
>
> On 11/15/23 4:01 PM, Nikita Provotorov wrote:
>
> Hello!
> I've discovered that on X11 platforms a call
> of java.awt.TextComponent#setText can lead to a call
> of javax.swing.JComponent#paintImmediately(java.awt.Rectangle) on the same
> thread.
> Since java.awt.TextComponent#setText is allowed to be called on any thread
> (because it's AWT, not Swing), JComponent#paintImmediately may be called
> outside of EDT. Is this a valid behavior?
>
> The following stacktrace shows how exactly this can happen:
>
>> at javax.swing.JComponent.paintImmediately
>> at sun.awt.X11.XTextAreaPeer$AWTTextArea.repaintNow
>> at sun.awt.X11.XTextAreaPeer.repaintText
>> at sun.awt.X11.XTextAreaPeer.setText
>> at java.awt.TextComponent.setText
>
>
> Best regards,
> Nikita Provotorov
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231117/de8c1821/attachment.htm>

From abhiscxk at openjdk.org  Fri Nov 17 15:00:49 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 17 Nov 2023 15:00:49 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <dp2SajUlqqSR5yMsvPCi_Bf6LZZBcBPPMz2ta1Dx4jY=.f1ac9324-11e9-48bd-ac69-a0fb276b6865@github.com>

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

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

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16467/files
  - new: https://git.openjdk.org/jdk/pull/16467/files/dc18817b..2e66e89e

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

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

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

From abhiscxk at openjdk.org  Fri Nov 17 15:00:54 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 17 Nov 2023 15:00:54 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <JVHf4whxLHnga9ANnEWcJi0vPlZRqCk0kTSk88lnqIQ=.bacacec0-1463-4a88-b155-302ddf4bb4e1@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <JVHf4whxLHnga9ANnEWcJi0vPlZRqCk0kTSk88lnqIQ=.bacacec0-1463-4a88-b155-302ddf4bb4e1@github.com>
Message-ID: <lDfikySJyubGIsiJjtks_pwmAXFbEPEl5VW1kgPq3vw=.d7d5756b-b29d-4e8f-9ad3-9749eaab563a@github.com>

On Thu, 16 Nov 2023 13:13:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 145:
> 
>> 143:     */
>> 144: 
>> 145:     private static boolean compareImage(BufferedImage img1, BufferedImage img2) {
> 
> You can use the method from `regtesthelpers/Util`:
> 
> https://github.com/openjdk/jdk/blob/9faead1469481e268b451f2853c8fec8613426b9/test/jdk/javax/swing/regtesthelpers/Util.java#L59-L80
> 
> If you don't want to use, I suggest reversing the conditions so that `compareImage` returns `true` when images are the same ? it's more common and therefore less confusing. In addition to that, return quickly if the sizes are different (can they ever be?) and avoid nesting the `for`-loops inside the `if` statement.

Updated the test to use the method from regtesthelpers/Util.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1397440923

From abhiscxk at openjdk.org  Fri Nov 17 15:00:51 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 17 Nov 2023 15:00:51 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <xcgorBsgsbKAyqJayux-6Hp7BJ7Md_kWr2oxtyuvIXY=.6402ef75-2e6a-4dcf-953a-8a090f78125f@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <BwvctAcFS0lydNNJwqQAy5E17XlhEVRtunISD8io25M=.93a56b10-2bcc-41d1-bbcc-27f46a0282ed@github.com>
 <6BikBxrPnwWw-8COtSImapKoXK9eEt6jz3xKAnVtfvk=.9ad1aac8-c9c1-423e-a539-bad4e9839174@github.com>
 <xcgorBsgsbKAyqJayux-6Hp7BJ7Md_kWr2oxtyuvIXY=.6402ef75-2e6a-4dcf-953a-8a090f78125f@github.com>
Message-ID: <WfHIcJCLMLSTtb52iuMmSVbg9cXQGFIL7QEXAXkXUwI=.6812bf3b-f869-4f71-a2bb-f804470a67ff@github.com>

On Thu, 16 Nov 2023 06:50:36 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I couldn't understand. Can you please explain a bit more?
>
> It is not necessary to add the progress bar to the frame and then capture the pixels by the robot. you can render content of the progress bar directly to the BufferedImage.

@mrserb @aivanov-jdk Updated the test to render component to `BufferedImage` directly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1397442893

From philip.race at oracle.com  Fri Nov 17 18:42:46 2023
From: philip.race at oracle.com (Philip Race)
Date: Fri, 17 Nov 2023 10:42:46 -0800
Subject: Is it valid to call JComponent#paintImmediately on a non-EDT
 thread (yet)?
In-Reply-To: <CAMTdVerbDWuq9s6yzcJYnChbefZGBSj-zJ2mxt7LbgCisK52_A@mail.gmail.com>
References: <CAMTdVeoVr=xzqsMHXeLdZR09G+O8U_AtwTTGS6xPj2PXTheWJw@mail.gmail.com>
 <895ab355-9586-4c49-8384-a660ae8483ae@oracle.com>
 <CAMTdVerbDWuq9s6yzcJYnChbefZGBSj-zJ2mxt7LbgCisK52_A@mail.gmail.com>
Message-ID: <796fa293-0824-444b-ae32-fe58edf3cc4b@oracle.com>

No, the code that calls setText() is where it starts.

-phil.

On 11/17/23 2:51 AM, Nikita Provotorov wrote:
> Thanks for the response!
> However I'd like?to clarify: is it correct to say that the current 
> implementation of sun.awt.X11.XTextAreaPeer#repaintText 
> <https://github.com/openjdk/jdk/blob/8ec6b8de3bb3d7aeebdcb45d761b18cce3bab75e/src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java#L258>?is 
> wrong because it doesn't make sure?if 
> /javax.swing.JComponent#paintImmediately/ is called on EDT only(e.g. 
> via/SwingUtilities#invokeLater/)?
>
> Best regards,
> Nikita Provotorov
>
>
> On Thu, Nov 16, 2023 at 9:30?PM Philip Race <philip.race at oracle.com> 
> wrote:
>
>     Because (like in this case), an AWT component might actually be
>     implemented using Swing,
>     the recommendation is to treat AWT components like Swing, and
>     update them only on the EDT.
>
>     -phil.
>
>     On 11/15/23 4:01 PM, Nikita Provotorov wrote:
>>     Hello!
>>     I've discovered that on X11 platforms a call
>>     of?java.awt.TextComponent#setText can lead to a call
>>     of?javax.swing.JComponent#paintImmediately(java.awt.Rectangle) on
>>     the same thread.
>>     Since java.awt.TextComponent#setText is allowed to be called on
>>     any thread (because it's AWT, not Swing),
>>     JComponent#paintImmediately may be called outside of EDT. Is this
>>     a valid behavior?
>>
>>     The following stacktrace shows how exactly this can happen:
>>
>>         at javax.swing.JComponent.paintImmediately
>>         at sun.awt.X11.XTextAreaPeer$AWTTextArea.repaintNow
>>         at sun.awt.X11.XTextAreaPeer.repaintText
>>         at sun.awt.X11.XTextAreaPeer.setText
>>         at java.awt.TextComponent.setText
>>
>>
>>     Best regards,
>>     Nikita Provotorov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231117/985f5103/attachment.htm>

From prr at openjdk.org  Fri Nov 17 18:50:57 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Nov 2023 18:50:57 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v28]
In-Reply-To: <ntTXWoJHJ5051MsaEZg9KMGsxyfLWGENoJMH_MNJ28Q=.a22df483-9b34-490c-a8a7-fbe89fcb3a50@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <ntTXWoJHJ5051MsaEZg9KMGsxyfLWGENoJMH_MNJ28Q=.a22df483-9b34-490c-a8a7-fbe89fcb3a50@github.com>
Message-ID: <7bKQMlhuI-R1N3nPYW-f-WrCPlk2u-7QfIzcmkPJkGE=.f0eb9f7b-5939-43ca-b58d-126310d49d0c@github.com>

On Fri, 17 Nov 2023 08:24:18 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Includes for awt_Component.cpp
>  - Likewise for awt_Component.cpp

src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 217:

> 215:         env->ExceptionClear();
> 216:         JNU_ThrowNullPointerException(env, "peer");
> 217:         env->DeleteGlobalRef(canvas);

you didn't code this up the way I did in my comment, which I think you should have done, and here you are deleting a ref to NULL, and the string passed to throw doesn't mention the canvas, which it can do unlike the old code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1397737624

From prr at openjdk.org  Fri Nov 17 19:00:36 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Nov 2023 19:00:36 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <WTqFbwkaCHA3dG6aKee4lpYxvodxIvnZv15Gos8usHA=.39448cb4-307b-461d-8e87-4e33a1dd7284@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

I'm not seeing anything I'd call truly bad here.
But I do have another suggestion that actually might have been the best thing to do all those years ago.
Keep the over-ride as the default behaviour, and document it better.
But if the app calls setMaximumSize or setMinimumSize() then honour it like you are supposed to.
 I suspect very few apps actually call these since they are complete no-ops today.
If we do that, then yes, you'll still see differences if you do call those APIs and forgot about it because it didn't make a difference.

If that isn't going to work, then, I think we should fall back to the pure documentation solution.
Well, almost pure docs, but not quite, because we need a no-op over-ride of set* on which to place the docs.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1816933906

From serb at openjdk.org  Fri Nov 17 19:01:40 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 17 Nov 2023 19:01:40 GMT
Subject: Integrated: 8319985: Delete sun.awt.windows.WToolkit.embedded*() API
In-Reply-To: <d1j-bRmojRZ1-KgV3Q6kmsU6c5TONl1AxPfYBEwkWug=.35131da9-dfa6-4f2f-a09f-10adf73de1d1@github.com>
References: <d1j-bRmojRZ1-KgV3Q6kmsU6c5TONl1AxPfYBEwkWug=.35131da9-dfa6-4f2f-a09f-10adf73de1d1@github.com>
Message-ID: <KxYNCKDh6hLrfngKMHow9f92CmCa5_r0UxPZCveAoUA=.c3e90644-6e6f-43f7-9834-9e3d5e1601ac@github.com>

On Mon, 13 Nov 2023 20:44:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Unused "embedded.." methods in the "sun.awt.windows.WToolkit" class were deleted.

This pull request has now been integrated.

Changeset: b5a7562b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b5a7562bd10998d50ae77429af1802333002197d
Stats:     149 lines in 3 files changed: 0 ins; 143 del; 6 mod

8319985: Delete sun.awt.windows.WToolkit.embedded*() API

Reviewed-by: prr

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

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

From honkar at openjdk.org  Fri Nov 17 19:42:32 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 17 Nov 2023 19:42:32 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <YL6MPpDMQbR3WmXkzR4v2PH1vNqkH36DoO7g1cH3qPE=.1c0d846e-defa-4a1e-87e3-78305ff99ea6@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <YL6MPpDMQbR3WmXkzR4v2PH1vNqkH36DoO7g1cH3qPE=.1c0d846e-defa-4a1e-87e3-78305ff99ea6@github.com>
Message-ID: <7_GyyYaoKXPJ2P1_JjhCaDz2s8FDx76rFqVVOW9S_jg=.97af838b-392a-4708-a399-df262e3de434@github.com>

On Wed, 15 Nov 2023 19:27:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   local var reused
>
> src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m line 417:
> 
>> 415:     if (getenv("AWT_DISABLE_NSDELEGATE_SECURE_SAVE") != NULL) {
>> 416:        supportsSecureState = NO;
>> 417:     }
> 
> I think that (and in the other case), it is best to read the env. var only once, not keep checking it on ever call to this method. Theoretically if someone used putenv/setenv (yes they'd need native code), it would cause us to change the answer.
> 
> Yes, this makes the code a bit more complicated but it will be safer.
> maybe you could maybe use static locals
> 
> <pre>
> (BOOL)applicationSupportsSecureRestorableState:(NSApplication *)app {
>      static BOOL checked = NO;
>      static BOOL supportsSecureState = YES;
>      if (checked == NO) {
>         checked = YES;
>         if (getenv("AWT_DISABLE_NSDELEGATE_SECURE_SAVE") != NULL) {
>             supportsSecureState = NO;
>      }
>      return supportsSecureState;
> }
>     
> </pre>

@prrace I think using static variables to read env variables only once is a good idea since I see `applicationSupportsSecureRestorableState()` being called every time the window loses focus.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1397789526

From aivanov at openjdk.org  Fri Nov 17 20:08:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Nov 2023 20:08:41 GMT
Subject: RFR: 8320303: Allow PassFailJFrame to accept single window creator
Message-ID: <j-rQt5NicpSozlOpkyvylyxN_r3FIBqLntXmmuvJ3e8=.85d33960-6e5e-4513-a6f3-fe283bbce43c@github.com>

Enhance `PassFailJFrame` for single-window test UI which is the most common case so that there's no need to return `List.of`.

With this change, the lambda or method reference passed to `Builder.testUI` will return Window instead of `List<Window>` (or `List<? extends Window>`.

This change adds new functional interface `WindowCreator` which returns a single Window; the existing interface is renamed to `WindowListCreator`.

It's backwards compatible change; the [FileChooserSymLinkTest.java](https://github.com/openjdk/jdk/blob/7f47c51aced9c724dbc9b0d8cbd88c49435da460/test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java) test which uses `Builder.testUI` works without change.

It was my main concern that it will be impossible to have two interfaces where one creates a `Windows` and another ? `List<Windows>`. The Java compiler automatically selects the correct method based on the return type of the lambda expression, so that both cases are supported. The requirement to return a `List` where only one window is needed bothered me, and I finally solved it.

In addition to that, I added description to all the overloads of the `Builder.testUI` method and updated the sample in the class documentation.

Since the `PassFailJFrame` class isn't supposed to be extended, I marked it `final` to prevent anyone from doing it.

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

Commit messages:
 - 8320303: Allow PassFailJFrame to accept single window creator

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

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

From aivanov at openjdk.org  Fri Nov 17 20:24:31 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Nov 2023 20:24:31 GMT
Subject: RFR: 8320303: Allow PassFailJFrame to accept single window creator
In-Reply-To: <j-rQt5NicpSozlOpkyvylyxN_r3FIBqLntXmmuvJ3e8=.85d33960-6e5e-4513-a6f3-fe283bbce43c@github.com>
References: <j-rQt5NicpSozlOpkyvylyxN_r3FIBqLntXmmuvJ3e8=.85d33960-6e5e-4513-a6f3-fe283bbce43c@github.com>
Message-ID: <TqwYik5Cz84lM3tdGXVaof3pbMVMS3gi_nU_m7dXhZI=.a97b5a83-2b9e-4d4a-8911-727473e69f3f@github.com>

On Fri, 17 Nov 2023 20:01:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Enhance `PassFailJFrame` for single-window test UI which is the most common case so that there's no need to return `List.of`.
> 
> With this change, the lambda or method reference passed to `Builder.testUI` will return Window instead of `List<Window>` (or `List<? extends Window>`.
> 
> This change adds new functional interface `WindowCreator` which returns a single Window; the existing interface is renamed to `WindowListCreator`.
> 
> It's backwards compatible change; the [FileChooserSymLinkTest.java](https://github.com/openjdk/jdk/blob/7f47c51aced9c724dbc9b0d8cbd88c49435da460/test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java) test which uses `Builder.testUI` works without change.
> 
> It was my main concern that it will be impossible to have two interfaces where one creates a `Windows` and another ? `List<Windows>`. The Java compiler automatically selects the correct method based on the return type of the lambda expression, so that both cases are supported. The requirement to return a `List` where only one window is needed bothered me, and I finally solved it.
> 
> In addition to that, I added description to all the overloads of the `Builder.testUI` method and updated the sample in the class documentation.
> 
> Since the `PassFailJFrame` class isn't supposed to be extended, I marked it `final` to prevent anyone from doing it.

The simplified usage is available in #16718.

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

PR Comment: https://git.openjdk.org/jdk/pull/16717#issuecomment-1817051486

From aivanov at openjdk.org  Fri Nov 17 20:28:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 17 Nov 2023 20:28:39 GMT
Subject: RFR: 8320349: Simplify FileChooserSymLinkTest.java by using
 single-window testUI
Message-ID: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>

Update `FileChooserSymLinkTest.java` to simplify its implementation by replacing `List<Window>` with `JFrame` of its `createTestUI` which now uses `PassFailJFrame.Builder testUI(PassFailJFrame.WindowCreator)` instead of `PassFailJFrame.Builder testUI(PassFailJFrame.WindowListCreator)`.

The test works correctly with and without the update.

This PR depends on #16717.

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

Depends on: https://git.openjdk.org/jdk/pull/16717

Commit messages:
 - 8320349: Simplify FileChooserSymLinkTest.java by using single-window testUI

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

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

From dnguyen at openjdk.org  Fri Nov 17 23:08:32 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 17 Nov 2023 23:08:32 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <dp2SajUlqqSR5yMsvPCi_Bf6LZZBcBPPMz2ta1Dx4jY=.f1ac9324-11e9-48bd-ac69-a0fb276b6865@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <dp2SajUlqqSR5yMsvPCi_Bf6LZZBcBPPMz2ta1Dx4jY=.f1ac9324-11e9-48bd-ac69-a0fb276b6865@github.com>
Message-ID: <o-bxcNcM3q3Vq4TjcqP_6HE52QUAM3dWqLqkgC18DY4=.50aebe20-b728-4f9d-b52f-55a54469d6bf@github.com>

On Fri, 17 Nov 2023 15:00:49 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Changes look logical and work as expected.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 70:

> 68:             isImgSame = Util.compareBufferedImages(borderPaintedImg, borderNotPaintedImg);
> 69: 
> 70:             if (isImgSame) {

Maybe worth renaming `isImgSame` to something that reads slightly smoother like `isImgEqual`, `isEqual`, or `isMatching`. Could just even inser the `Util.compareBufferedImages()` into the if statement for the failure check if you prefer. But I like the variable for better readability.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 92:

> 90:     private static void createAndShowUI() {
> 91:         progressBar = new JProgressBar();
> 92:         progressBar.setSize(100,50);

Suggestion:

        progressBar.setSize(100, 50);

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16467#pullrequestreview-1738070215
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1397976092
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1397974704

From prr at openjdk.org  Fri Nov 17 23:26:31 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 17 Nov 2023 23:26:31 GMT
Subject: RFR: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
Message-ID: <56ovevzbFFEFApGE8-gN1ZjzpKgaRx1mgT9ZORiz1tU=.3842c478-b6ce-4355-8a14-9eb91662dceb@github.com>

On Thu, 12 Oct 2023 15:51:28 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
> The same is true for `CustomMediaTray` class.
> 
> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
> 
> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.

TLDR; I suspect your problem can be solved with a one line check for null, but there's still value in more changes.

The long story
So I was a bit surprised that CUPSPrinter.initMedia() was being called over and over.

I looked into it and it starts with the following which goes all the way back to JDK 1.5
    public synchronized PrintServiceAttributeSet getAttributes() {
        // update getAttMap by sending again get-attributes IPP request
        init = false;
        initAttributes();
....

  }

This means EVERY call to IPPPrintService.getAttributes() re-initialises all attributes.
And that method returns just the service attributes which are 
    private static Object[][] serviceAttributes = {
        {ColorSupported.class, "color-supported"},
        {PagesPerMinute.class,  "pages-per-minute"},
        {PagesPerMinuteColor.class, "pages-per-minute-color"},
        {PDLOverrideSupported.class, "pdl-override-supported"},
        {PrinterInfo.class, "printer-info"},
        {PrinterIsAcceptingJobs.class, "printer-is-accepting-jobs"},
        {PrinterLocation.class, "printer-location"},
        {PrinterMakeAndModel.class, "printer-make-and-model"},
        {PrinterMessageFromOperator.class, "printer-message-from-operator"},
        {PrinterMoreInfo.class, "printer-more-info"},
        {PrinterMoreInfoManufacturer.class, "printer-more-info-manufacturer"},
        {PrinterName.class, "printer-name"},
        {PrinterState.class, "printer-state"},
        {PrinterStateReasons.class, "printer-state-reasons"},
        {PrinterURI.class, "printer-uri"},
        {QueuedJobCount.class, "queued-job-count"}
    };      

I can see this being important for some service attributes, like whether the printer is up and running,
and how many jobs in the queue but is complete over-kill for all the static attributes.
I'm pretty sure it won't suddenly become a color printer ...
and then on top of that it is re-initialising all the media , which is where your problem starts
because when init is false, a call to initAttributes does this :

                    cps = new CUPSPrinter(printer);
                    mediaSizeNames = cps.getMediaSizeNames();
                    mediaTrays = cps.getMediaTrays();
                    customMediaSizeNames = cps.getCustomMediaSizeNames();
                    defaultMediaIndex = cps.getDefaultMediaIndex();
                    rawResolutions = cps.getRawResolutions();

That's why you are seeing so many calls to initMedia()
This ought to be guarded by
if (cps == null) {
    ...
}
That small change would make your specific CUPS.initMedia() problem go away

if we want to do fine-grained checking for whether the default media has changed, we could do that but
we also perhaps (not sure) could check if the PPD is actually updated since the last read.
But I don't see a need - the calls to get the media don't do the re-initialisation, its just the one
to get the service attributes.



But that is not a complete solution, even if you never hit this case where if it is not a cups printer, we go to IPP,
            // use IPP to get all media,
            Media[] allMedia = getSupportedMedia();

that's going to do the same re-creation of all the custom media so your map still helps there, even if the null check is added.

But I'm not sure why we are redoing that work either, so it goes back to the "init=false" being over-kill

I think we need to stop setting init=false and get just what we need.

Like we need a "re-init" that handles this.

Right now, I'm inclined to suggest you push the fix you have (modulo my existing comments that need to be addressed)
and I'll file a separate bug for what I think we should do to avoid this in the first place.

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

PR Comment: https://git.openjdk.org/jdk/pull/16167#issuecomment-1817243511

From prr at openjdk.org  Sat Nov 18 01:17:29 2023
From: prr at openjdk.org (Phil Race)
Date: Sat, 18 Nov 2023 01:17:29 GMT
Subject: RFR: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
Message-ID: <eAJzRe7a1K97SybZ-82dvNhcOhUw5a3vOa2VlR9jPYI=.29d2ced6-cb11-4a7d-bfae-005dd9663ed8@github.com>

On Thu, 12 Oct 2023 15:51:28 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
> The same is true for `CustomMediaTray` class.
> 
> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
> 
> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.

I submitted https://bugs.openjdk.org/browse/JDK-8320365 and I'll take care of it. Perhaps for 22 but time is getting short there.

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

PR Comment: https://git.openjdk.org/jdk/pull/16167#issuecomment-1817305474

From jwaters at openjdk.org  Sat Nov 18 14:02:45 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 18 Nov 2023 14:02:45 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v28]
In-Reply-To: <7bKQMlhuI-R1N3nPYW-f-WrCPlk2u-7QfIzcmkPJkGE=.f0eb9f7b-5939-43ca-b58d-126310d49d0c@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <ntTXWoJHJ5051MsaEZg9KMGsxyfLWGENoJMH_MNJ28Q=.a22df483-9b34-490c-a8a7-fbe89fcb3a50@github.com>
 <7bKQMlhuI-R1N3nPYW-f-WrCPlk2u-7QfIzcmkPJkGE=.f0eb9f7b-5939-43ca-b58d-126310d49d0c@github.com>
Message-ID: <cwYJ5bZhQ7tYzhjkx7md6iYjN-_ly-miqc2lqQNJFsM=.7747870e-dde8-4533-a000-592ad650ffd9@github.com>

On Fri, 17 Nov 2023 18:47:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Includes for awt_Component.cpp
>>  - Likewise for awt_Component.cpp
>
> src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 217:
> 
>> 215:         env->ExceptionClear();
>> 216:         JNU_ThrowNullPointerException(env, "peer");
>> 217:         env->DeleteGlobalRef(canvas);
> 
> you didn't code this up the way I did in my comment, which I think you should have done, and here you are deleting a ref to NULL, and the string passed to throw doesn't mention the canvas, which it can do unlike the old code.

Sorry, I was trying to keep as close to the original code as possible. Woah, does that mean the original was bugged, since it was deleting a NULL canvas? Anyway, should I change the string to canvas or just keep it as "peer" like the original code does in that case?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1398213842

From tr at openjdk.org  Mon Nov 20 05:10:36 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 05:10:36 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v4]
In-Reply-To: <AdayEi5Y-2tz6h19hBrZZVbSwoF9OMbfRJ1gLkTCnu0=.c726f344-d0c9-47bc-8f10-afb621ae2aa8@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <LUZ0alzQIQIjwMppiucY2kmKe1tRxpB6oLVUSIXDKcw=.bc5558a3-41f2-4557-b9dc-c58ff2e232a8@github.com>
 <XW1JMlBS-NCW_yWgSVTJbJBbJtT_cEAOFlWAK9sL1bI=.ae3d9a68-753a-4438-85bb-f7f6ef6ba54a@github.com>
 <AdayEi5Y-2tz6h19hBrZZVbSwoF9OMbfRJ1gLkTCnu0=.c726f344-d0c9-47bc-8f10-afb621ae2aa8@github.com>
Message-ID: <os7YbswmIEiy3LU9dFqhKfQP6wY212bkC6ZYBdO8Tso=.41d4783d-80b9-4ab2-8665-b2e0c80571ef@github.com>

On Thu, 16 Nov 2023 19:09:34 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 603:
>> 
>>> 601:             }
>>> 602:         } else {
>>> 603:             for(int row = rMin; row <= rMax; row++) {
>> 
>> Suggestion:
>> 
>>             for (int row = rMin; row <= rMax; row++) {
>
> it's just a spacing thing, but should these be left alone since they weren't changed with the fix?

Yeah, not sure whether update this or not. Anyhow will update for uniformity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398667800

From tr at openjdk.org  Mon Nov 20 05:24:51 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 05:24:51 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/9f0bfb4e..6e25fb36

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

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

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

From abhiscxk at openjdk.org  Mon Nov 20 05:28:50 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 20 Nov 2023 05:28:50 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v3]
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

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

  Minor fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16467/files
  - new: https://git.openjdk.org/jdk/pull/16467/files/2e66e89e..7f1b1eaa

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

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

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

From abhiscxk at openjdk.org  Mon Nov 20 05:28:53 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 20 Nov 2023 05:28:53 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <o-bxcNcM3q3Vq4TjcqP_6HE52QUAM3dWqLqkgC18DY4=.50aebe20-b728-4f9d-b52f-55a54469d6bf@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <dp2SajUlqqSR5yMsvPCi_Bf6LZZBcBPPMz2ta1Dx4jY=.f1ac9324-11e9-48bd-ac69-a0fb276b6865@github.com>
 <o-bxcNcM3q3Vq4TjcqP_6HE52QUAM3dWqLqkgC18DY4=.50aebe20-b728-4f9d-b52f-55a54469d6bf@github.com>
Message-ID: <f7X5cjFhVBKQBMkFBqyIzwwCedv0gOoXvbPGdbQx90g=.00e80aa4-3e1b-462e-a809-e0fc284c6a63@github.com>

On Fri, 17 Nov 2023 23:04:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 70:
> 
>> 68:             isImgSame = Util.compareBufferedImages(borderPaintedImg, borderNotPaintedImg);
>> 69: 
>> 70:             if (isImgSame) {
> 
> Maybe worth renaming `isImgSame` to something that reads slightly smoother like `isImgEqual`, `isEqual`, or `isMatching`. Could just even inser the `Util.compareBufferedImages()` into the if statement for the failure check if you prefer. But I like the variable for better readability.

Updated to `isImgEqual`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1398676201

From psadhukhan at openjdk.org  Mon Nov 20 06:42:40 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Nov 2023 06:42:40 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
Message-ID: <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com>

On Wed, 25 Oct 2023 23:42:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

src/java.desktop/share/classes/sun/font/HBShaper.java line 628:

> 626:         MemorySegment glyphInfoArr = glyphInfo.reinterpret(glyphInfoSize);
> 627: 
> 628:          for (int i=0; i<glyphCount; i++) {

Spacing between operators

src/java.desktop/share/classes/sun/font/HBShaper.java line 658:

> 656:         startPt.x = advX;
> 657:         startPt.y = advY;
> 658:         startPt.x = advX;

duplicate assignment of startPt.x to advX...

src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 167:

> 165:     }
> 166: 
> 167:     static boolean useFFM = true;

So, we want to enable FFM by default?

src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 184:

> 182:         FontStrike strike = font.getStrike(desc);
> 183:         if (useFFM) {
> 184:             java.lang.foreign.MemorySegment face = HBShaper.getFace(font);

Guess import at start will be more nicer...

src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c line 141:

> 139:      hb_buffer_destroy (buffer);
> 140:      hb_font_destroy(hbfont);
> 141:      if (features != NULL) free(features);

Guess coding style warrants braces { and next statement in separate line...

src/java.desktop/share/native/libfontmanager/hb-jdk-font-p.cc line 238:

> 236:                       HBFloatToFixed(ptSize*devScale),
> 237:                       HBFloatToFixed(ptSize*devScale));
> 238:   return font;

indentation is off..

test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 29:

> 27: /*
> 28:    @test
> 29:    @summary verify JNI and FFM harfbuzz OpenType layout implementations are equivalent.

bug id is missing

test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 45:

> 43: public class LayoutCompatTest {
> 44: 
> 45:    static String jni = "jni.txt";

Seems test is failing without fix with Exception in jtreg
java.io.FileNotFoundException: jni.txt (The system cannot find the file specified)

Also in standalone mode. I was expecting it will fail with RuntimeException "files differ byte offset"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395720270
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395721851
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395723605
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395726378
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395748600
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395750344
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395752417
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1395788998

From abhiscxk at openjdk.org  Mon Nov 20 06:59:57 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 20 Nov 2023 06:59:57 GMT
Subject: Integrated: 8283214: [macos] Screen magnifier does not show the
 magnified text for JcomboBox
In-Reply-To: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
References: <y6Ss3mXiXSQq_SRtsdIzpeyTA4tH0QGV8zjVNMkzqs0=.7e3b9e73-7bd1-450e-9cd1-6276c345b79e@github.com>
Message-ID: <NVPGf2ikdyBcekskQf_hPfiKIMR1gTMySRNGeg6FVeY=.faf2b4af-9f38-4dbd-b7fc-a39e17af8dc7@github.com>

On Thu, 15 Jun 2023 15:58:18 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> The issue exist only for non-editable combobox and the root cause is accessible object is not created due to incorrect index returned from component class which results in no a11y API invoked.
> 
> Proposed solution is to return the correct accessible child from getAccessibleChild method which is AquaComboBoxButton (arrowButton) instance and that results in invoking the a11y APIs to return the current selected item in combobox. 
> 
> Further when the application comes up first time the accessible name is not set for current displayed item in JCombobox that is handled in AquaComboBoxButton which will take care for the current selected item as well as if user modifies the selection by drop-down list.
> 
> CI link is posted in JBS.

This pull request has now been integrated.

Changeset: de51aa19
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de51aa19d6a8cbd3b83bf469cb89da16f4b6f498
Stats:     178 lines in 4 files changed: 167 ins; 2 del; 9 mod

8283214: [macos] Screen magnifier does not show the magnified text for JcomboBox

Co-authored-by: Alexey Ivanov <aivanov at openjdk.org>
Reviewed-by: asemenov, kizune, aivanov

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

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

From psadhukhan at openjdk.org  Mon Nov 20 09:53:38 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Nov 2023 09:53:38 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
Message-ID: <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>

On Mon, 20 Nov 2023 05:24:51 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

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

> 2085:             for (int row = rMin; row <= rMax; row++) {
> 2086:                 cellRect = table.getCellRect(row, cMin, false);
> 2087:                 cellRect.x = getXPosition(cMin);

Why do we need to calculate cellRect.x separately? What is wrong in getting the value already there in `cellRect` ?

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

> 2099:             for (int row = rMin; row <= rMax; row++) {
> 2100:                 cellRect = table.getCellRect(row, cMin, false);
> 2101:                 cellRect.x = getXPosition(cMax);

Is this not a problem that `cellRect` is calculated for `cMin` but `cellRect.x` is calculated for `cMax` which means `cellRect.y` would be of `cMin` column but `cellRect.x` would be of `cMax` column. SImilarly for the `cellRect.width`...You probably can get away maybe because usually all cells have same width but I guess it will be a problem if different cells have different width...Please check..

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

> 2100:                 cellRect = table.getCellRect(row, cMin, false);
> 2101:                 cellRect.x = getXPosition(cMax);
> 2102:                 for (int column = cMax; column >= cMin; column--) {

Is there any reason for choosing to paint from cMax to cMin ie from left-to-right in RTL orientation
when it was done from right-to-left before your fix? 
I guess painting from right-to-left also should work with cellRect.x -= columnWidth ie with no change in code, no?

One more q,
If there are 5 columns, then is it that for LTR cMin is 1, cMax 5 and for RTL cMin is 5 , cMax 1 or viceversa?

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 611:

> 609:                     cellRect.width = columnWidth - columnMargin;
> 610:                     paintCell(context, g, cellRect, row, cMax);
> 611:                 }

I guess you removed this in BasicTableUI...Any particular reason for keeping this for Synth..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398918527
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398858032
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398883285
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398925522

From psadhukhan at openjdk.org  Mon Nov 20 09:53:41 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Nov 2023 09:53:41 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
 <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
Message-ID: <MiYDc9ORzI27_NlKNO4RiTtNz5Pys2W13ChbsmMBGJI=.bc1677ce-5283-4780-b911-f218d1d05d80@github.com>

On Tue, 7 Nov 2023 04:09:21 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 64:
>> 
>>> 62: 
>>> 63:     public static void main(String[] args) throws Exception {
>>> 64:         UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
>> 
>> Should this test run on all L&F? Since part of the fix occurs in BasicTableUI.
>
> I couldn't find a way to generalize the automatic test for all L&F, though I tested all manually.

Since this PR touches Synth, there should a regression testcase for Synth L&F too..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398927997

From tr at openjdk.org  Mon Nov 20 10:03:33 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 10:03:33 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
Message-ID: <Yhv59mcMZ_WxyaRsp85O90pqaKuIwoX-w-SniYSvArA=.7812a4f6-93f7-4184-90ec-98b04f70e1e0@github.com>

On Mon, 20 Nov 2023 09:15:46 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2101:
> 
>> 2099:             for (int row = rMin; row <= rMax; row++) {
>> 2100:                 cellRect = table.getCellRect(row, cMin, false);
>> 2101:                 cellRect.x = getXPosition(cMax);
> 
> Is this not a problem that `cellRect` is calculated for `cMin` but `cellRect.x` is calculated for `cMax` which means `cellRect.y` would be of `cMin` column but `cellRect.x` would be of `cMax` column. SImilarly for the `cellRect.width`...You probably can get away maybe because usually all cells have same width but I guess it will be a problem if different cells have different width...Please check..

Yeah, seems logical. It must `cMax`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398941524

From psadhukhan at openjdk.org  Mon Nov 20 10:07:32 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Nov 2023 10:07:32 GMT
Subject: RFR: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
Message-ID: <Qg8NPWUzyer14_Lju4zcNkSng4DZKtA0h_yqxp7Tk3A=.87d9b8b4-2fef-4e25-bf70-bf19bdd79b87@github.com>

On Thu, 12 Oct 2023 15:51:28 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
> The same is true for `CustomMediaTray` class.
> 
> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
> 
> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.

test/jdk/javax/print/CustomMediaSizeNameOOMETest.java line 37:

> 35: 
> 36: public class CustomMediaSizeNameOOMETest {
> 37: 

Seems testcase is passing for me even without the fix in windows

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16167#discussion_r1398946685

From tr at openjdk.org  Mon Nov 20 10:14:38 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 10:14:38 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <MiYDc9ORzI27_NlKNO4RiTtNz5Pys2W13ChbsmMBGJI=.bc1677ce-5283-4780-b911-f218d1d05d80@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
 <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
 <MiYDc9ORzI27_NlKNO4RiTtNz5Pys2W13ChbsmMBGJI=.bc1677ce-5283-4780-b911-f218d1d05d80@github.com>
Message-ID: <7zfCJtwbOxHNgMUjFftwjvXwx_ktjDWBDvVP_Bmco64=.2c57604f-ccf6-4455-ad90-4c919bb34fb5@github.com>

On Mon, 20 Nov 2023 09:50:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> I couldn't find a way to generalize the automatic test for all L&F, though I tested all manually.
>
> Since this PR touches Synth, there should a regression testcase for Synth L&F too..

Ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398954767

From tr at openjdk.org  Mon Nov 20 10:14:36 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 10:14:36 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
Message-ID: <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>

On Mon, 20 Nov 2023 09:45:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2087:
> 
>> 2085:             for (int row = rMin; row <= rMax; row++) {
>> 2086:                 cellRect = table.getCellRect(row, cMin, false);
>> 2087:                 cellRect.x = getXPosition(cMin);
> 
> Why do we need to calculate cellRect.x separately? What is wrong in getting the value already there in `cellRect` ?

The value we get from `table.getCellRect(row, cMin, false);` doesn't consider x position offset, so we need to update with the offset value.

> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2102:
> 
>> 2100:                 cellRect = table.getCellRect(row, cMin, false);
>> 2101:                 cellRect.x = getXPosition(cMax);
>> 2102:                 for (int column = cMax; column >= cMin; column--) {
> 
> Is there any reason for choosing to paint from cMax to cMin ie from left-to-right in RTL orientation
> when it was done from right-to-left before your fix? 
> I guess painting from right-to-left also should work with cellRect.x -= columnWidth ie with no change in code, no?
> 
> One more q,
> If there are 5 columns, then is it that for LTR cMin is 1, cMax 5 and for RTL cMin is 5 , cMax 1 or viceversa?

Yes, we can either paint from right-to-left or from left-to-right. I followed `JTableHeader ` paint logic.  for 5 columns cMin = 0 and cMax = 4.

> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 611:
> 
>> 609:                     cellRect.width = columnWidth - columnMargin;
>> 610:                     paintCell(context, g, cellRect, row, cMax);
>> 611:                 }
> 
> I guess you removed this in BasicTableUI...Any particular reason for keeping this for Synth..

Nothing particular, can remove and update there too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398953181
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398951260
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398954259

From psadhukhan at openjdk.org  Mon Nov 20 10:26:37 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Nov 2023 10:26:37 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <WTqFbwkaCHA3dG6aKee4lpYxvodxIvnZv15Gos8usHA=.39448cb4-307b-461d-8e87-4e33a1dd7284@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
 <WTqFbwkaCHA3dG6aKee4lpYxvodxIvnZv15Gos8usHA=.39448cb4-307b-461d-8e87-4e33a1dd7284@github.com>
Message-ID: <6MAafKiOw6fOqV0osYGb6Zjb9ZPqBrzZZIfB_SUQZ2Q=.7e5a1007-ce51-4b82-8d8d-c7a6bfbb6be3@github.com>

On Fri, 17 Nov 2023 18:57:29 GMT, Phil Race <prr at openjdk.org> wrote:

> I'm not seeing anything I'd call truly bad here. But I do have another suggestion that actually might have been the best thing to do all those years ago. Keep the over-ride as the default behaviour, and document it better. But if the app calls setMaximumSize or setMinimumSize() then honour it like you are supposed to. I suspect very few apps actually call these since they are complete no-ops today. If we do that, then yes, you'll still see differences if you do call those APIs and forgot about it because it didn't make a difference.
> 
> If that isn't going to work, then, I think we should fall back to the pure documentation solution. Well, almost pure docs, but not quite, because we need a no-op over-ride of set* on which to place the docs.

Do you mean this way https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=01#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java what I had done in the initial iteration? I guess that change will still show the above problem during frame resize, where scrollbars are not rigid

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1818768822

From psadhukhan at openjdk.org  Mon Nov 20 10:28:34 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Nov 2023 10:28:34 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
Message-ID: <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>

On Mon, 20 Nov 2023 10:10:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2087:
>> 
>>> 2085:             for (int row = rMin; row <= rMax; row++) {
>>> 2086:                 cellRect = table.getCellRect(row, cMin, false);
>>> 2087:                 cellRect.x = getXPosition(cMin);
>> 
>> Why do we need to calculate cellRect.x separately? What is wrong in getting the value already there in `cellRect` ?
>
> The value we get from `table.getCellRect(row, cMin, false);` doesn't consider x position offset, so we need to update with the offset value.

getCellRect spec says
`Returns a rectangle for the cell that lies at the intersection of row and column`

What's the x position offset we are talking here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398979460

From tr at openjdk.org  Mon Nov 20 10:43:33 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 10:43:33 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
Message-ID: <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>

On Mon, 20 Nov 2023 10:26:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> The value we get from `table.getCellRect(row, cMin, false);` doesn't consider x position offset, so we need to update with the offset value.
>
> getCellRect spec says
> `Returns a rectangle for the cell that lies at the intersection of row and column`
> 
> What's the x position offset we are talking here?

For RTL orientation [`getCellRect`](https://github.com/openjdk/jdk/blob/6c5e15c1a291ca5ba1e4c3a90351bc71665ce988/src/java.desktop/share/classes/javax/swing/JTable.java#L2977)  returns position excluding the Offset meaning the gap between panel x till x position of table which is x position of first column.  So instead of modifying at JTable class, I am updating here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1398998668

From psadhukhan at openjdk.org  Mon Nov 20 10:59:33 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 20 Nov 2023 10:59:33 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
 <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
Message-ID: <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>

On Mon, 20 Nov 2023 10:41:15 GMT, Tejesh R <tr at openjdk.org> wrote:

>> getCellRect spec says
>> `Returns a rectangle for the cell that lies at the intersection of row and column`
>> 
>> What's the x position offset we are talking here?
>
> For RTL orientation [`getCellRect`](https://github.com/openjdk/jdk/blob/6c5e15c1a291ca5ba1e4c3a90351bc71665ce988/src/java.desktop/share/classes/javax/swing/JTable.java#L2977)  returns position excluding the Offset meaning the gap between panel x till x position of table which is x position of first column.  So instead of modifying at JTable class, I am updating here.

but we dont seem to have any issue with LTR rendering, so why this getXPosition is needed for LTR too?
Also, wouldn't existing `getRowMargin` have helped?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399024012

From tr at openjdk.org  Mon Nov 20 10:59:34 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 10:59:34 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <7zfCJtwbOxHNgMUjFftwjvXwx_ktjDWBDvVP_Bmco64=.2c57604f-ccf6-4455-ad90-4c919bb34fb5@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
 <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
 <MiYDc9ORzI27_NlKNO4RiTtNz5Pys2W13ChbsmMBGJI=.bc1677ce-5283-4780-b911-f218d1d05d80@github.com>
 <7zfCJtwbOxHNgMUjFftwjvXwx_ktjDWBDvVP_Bmco64=.2c57604f-ccf6-4455-ad90-4c919bb34fb5@github.com>
Message-ID: <S_eW_y5oHOip-c10NZEszQloUxYB9Ij8DZYb0E1SPps=.321499f5-c60b-4864-a062-d8a3bf614847@github.com>

On Mon, 20 Nov 2023 10:11:27 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Since this PR touches Synth, there should a regression testcase for Synth L&F too..
>
> Ok.

But the current logic in test doesn't hold good for few Look and Feel including Nimbus. Should I make the test as manual mentioning it to be tested against all Look and Feel?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399022599

From tr at openjdk.org  Mon Nov 20 11:17:31 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 20 Nov 2023 11:17:31 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
 <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
 <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>
Message-ID: <4uoJqnLaar5XxFo7DHAK6dlUrUvjbiSP7q6re1toGNk=.24206fc2-99cc-46b1-89f0-be14e79d9c3a@github.com>

On Mon, 20 Nov 2023 10:56:59 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> For RTL orientation [`getCellRect`](https://github.com/openjdk/jdk/blob/6c5e15c1a291ca5ba1e4c3a90351bc71665ce988/src/java.desktop/share/classes/javax/swing/JTable.java#L2977)  returns position excluding the Offset meaning the gap between panel x till x position of table which is x position of first column.  So instead of modifying at JTable class, I am updating here.
>
> but we dont seem to have any issue with LTR rendering, so why this getXPosition is needed for LTR too?
> Also, wouldn't existing `getRowMargin` have helped?

LTR rendering will work unless the Table is fully occupied w.r.t the Panel. Here the Max width of each column is set which is less than the Panel size where extra space would be there on left side of the Table. LTR doesn't need getXPosition because it'll always be 0/attached to Panel at left position. In JTableHeader [r.x](https://github.com/openjdk/jdk/blob/6c5e15c1a291ca5ba1e4c3a90351bc71665ce988/src/java.desktop/share/classes/javax/swing/table/JTableHeader.java#L399) is computed on this offset basis.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399044562

From aivanov at openjdk.org  Mon Nov 20 12:57:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Nov 2023 12:57:34 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
Message-ID: <GnN1P9Pe5E2e68nwW4zoHsG-wNWqpNcGDnRAOA7ehWs=.b40c23a3-ed93-4cd6-b158-391247d3c759@github.com>

On Mon, 6 Nov 2023 06:22:33 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> javadoc contract for JComponent.setMinimumSize(Dimension) states:
>> 
>> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
>> 
>> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
>> 
>> Fix is made to check if mnimumSize is set and if so, honour it..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reinstate setEnabled

> > But I do have another suggestion that actually might have been the best thing to do all those years ago. Keep the over-ride as the default behaviour, and document it better. But if the app calls setMaximumSize or setMinimumSize() then honour it like you are supposed to. I suspect very few apps actually call these since they are complete no-ops today. If we do that, then yes, you'll still see differences if you do call those APIs and forgot about it because it didn't make a difference.
> 
> Do you mean this way https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=01#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java what I had done in the initial iteration? I guess that change will still show the above problem during frame resize, where scrollbars are not rigid

This is how I understand Phil's comment.

> I guess that change will still show the above problem during frame resize, where scrollbars are not rigid

Yes, it will, this is why update to the javadoc of `getMinimumSize` and `getMaximumSize` is required?to document their default behaviour and the fallback to returning the set sizes as per `JComponent` specification of `setMinimumSize` and `setMaximumSize`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15325#issuecomment-1819012794

From aivanov at openjdk.org  Mon Nov 20 14:42:28 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Nov 2023 14:42:28 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v3]
In-Reply-To: <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>
Message-ID: <T8e5aDDEDNSIqlN5Sc5PNUilTc3PvNvJi8wQkJxrckQ=.d679d743-a29f-4df3-890c-9c587ca5d59f@github.com>

On Mon, 20 Nov 2023 05:28:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fix

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 33:

> 31:  *          painting is set to false
> 32:  * @run main TestProgressBarBorder
> 33:  */

Could you move the tags closer to the class declaration, after the imports, please?

When the tags are before the class, they're not collapsed along with the copyright header when viewed in an IDE, which makes them easily visible.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 51:

> 49:     private static volatile boolean isImgEqual;
> 50:     private static BufferedImage borderPaintedImg;
> 51:     private static BufferedImage borderNotPaintedImg;

All these could be local variables.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 63:

> 61:                 setLookAndFeel(laf);
> 62:                 createAndShowUI();
> 63:             });

Do everything on EDT or don't bother with EDT: mixing it in this way isn't good.

In this case, it's safe to call the methods you use on the main thread. However, I heard that there's a convention to run all the code on EDT. Whatever you choose? but at least don't mix the threads.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 67:

> 65:             borderPaintedImg = paintToImage(progressBar);
> 66:             progressBar.setBorderPainted(false);
> 67:             borderNotPaintedImg = paintToImage(progressBar);

~~You may want to call `progressBar.setBorderPainted(true)` explicitly?this way the test will not depend on the default value. If whatever reason the default value changes, the test will become useless? it will be testing with `isBorderPainted == false` in both cases.~~
You're setting it in `createAndShowUI`; I still think it's better to move the call to `progressBar.setBorderPainted(true)` here.

Aren't `withBorder` and `withoutBorder` more succinct names?

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 90:

> 88:     }
> 89: 
> 90:     private static void createAndShowUI() {

It doesn't show the UI anymore, `createProgressBar` or `initProgressBar` will be a better name.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 93:

> 91:         progressBar = new JProgressBar();
> 92:         progressBar.setSize(100, 50);
> 93:         // set initial value

The comment is redundant, isn't it?

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

PR Review: https://git.openjdk.org/jdk/pull/16467#pullrequestreview-1739937455
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1399275705
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1399285139
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1399284233
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1399289964
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1399294763
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1399295252

From aivanov at openjdk.org  Mon Nov 20 14:42:31 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Nov 2023 14:42:31 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <f7X5cjFhVBKQBMkFBqyIzwwCedv0gOoXvbPGdbQx90g=.00e80aa4-3e1b-462e-a809-e0fc284c6a63@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <dp2SajUlqqSR5yMsvPCi_Bf6LZZBcBPPMz2ta1Dx4jY=.f1ac9324-11e9-48bd-ac69-a0fb276b6865@github.com>
 <o-bxcNcM3q3Vq4TjcqP_6HE52QUAM3dWqLqkgC18DY4=.50aebe20-b728-4f9d-b52f-55a54469d6bf@github.com>
 <f7X5cjFhVBKQBMkFBqyIzwwCedv0gOoXvbPGdbQx90g=.00e80aa4-3e1b-462e-a809-e0fc284c6a63@github.com>
Message-ID: <JA44zEvaZWFx91FMstOaSSN_Km0Pwsy3qXDAD_ANmL0=.17b6acb4-7c55-43f7-a802-8eb66f1c650c@github.com>

On Mon, 20 Nov 2023 05:24:59 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 70:
>> 
>>> 68:             isImgSame = Util.compareBufferedImages(borderPaintedImg, borderNotPaintedImg);
>>> 69: 
>>> 70:             if (isImgSame) {
>> 
>> Maybe worth renaming `isImgSame` to something that reads slightly smoother like `isImgEqual`, `isEqual`, or `isMatching`. Could just even inser the `Util.compareBufferedImages()` into the if statement for the failure check if you prefer. But I like the variable for better readability.
>
> Updated to `isImgEqual`.

Grammatically, it should be `areImgsEqual` or `areImagesEqual`.

Would `boolean equal = Util.compareBufferedImages` be enough to convey the meaning?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1399299440

From aivanov at openjdk.org  Mon Nov 20 15:46:37 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Nov 2023 15:46:37 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <brio-R7SyRbaEVJbGT69o4M8kt2ORANLsKF49MyK0Ec=.4bbb05f9-801c-4333-9168-16f3ddedb15c@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
 <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
 <brio-R7SyRbaEVJbGT69o4M8kt2ORANLsKF49MyK0Ec=.4bbb05f9-801c-4333-9168-16f3ddedb15c@github.com>
Message-ID: <SJp-JLPgy69_t4S6jSHeICrFiIECMiSwYJiClohaigU=.2cbf21a3-3f4f-4c5f-ab06-993fd0f4163c@github.com>

On Wed, 15 Nov 2023 19:17:14 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> U mean to create a test directory and store image there?
>
> Not a new test directory. In that referenced PR, I had to get the path to the directory where test files are stored temporarily. This helps with testing mainly.
> 
> `Path.of(System.getProperty("test.classes", "."));` was the path I used in the PR. I saved it to a var and wrote the image to that var followed by the image name.

When run with jtreg, the current directory is the scratch directory which is thrown away if the test passes or stored by the harness if the test fails. It is safe to use it this way, many tests do save images like this.

Your case was somewhat different: you creating and saving an image for the test use. I guess it could also do without the extra stuff, however, preserving the generated image if the test fails may be unnecessary.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399394072

From aivanov at openjdk.org  Mon Nov 20 15:53:40 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Nov 2023 15:53:40 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <S_eW_y5oHOip-c10NZEszQloUxYB9Ij8DZYb0E1SPps=.321499f5-c60b-4864-a062-d8a3bf614847@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
 <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
 <MiYDc9ORzI27_NlKNO4RiTtNz5Pys2W13ChbsmMBGJI=.bc1677ce-5283-4780-b911-f218d1d05d80@github.com>
 <7zfCJtwbOxHNgMUjFftwjvXwx_ktjDWBDvVP_Bmco64=.2c57604f-ccf6-4455-ad90-4c919bb34fb5@github.com>
 <S_eW_y5oHOip-c10NZEszQloUxYB9Ij8DZYb0E1SPps=.321499f5-c60b-4864-a062-d8a3bf614847@github.com>
Message-ID: <vY5L6B6JthT0t41NATp_atUu22sTOte-ln7gdbbQob4=.7c09d906-5b17-44ad-b117-ab9971f3544f@github.com>

On Mon, 20 Nov 2023 10:55:47 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Ok.
>
> But the current logic in test doesn't hold good for few Look and Feel including Nimbus. Should I make the test as manual mentioning it to be tested against all Look and Feel?

You can have two tests: for Metal and for Synth (Nimbus).

A manual test is an option too, but if you can automate each separate L&F, you should definitely do it: an automatic test will be run regularly and often.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399403919

From aivanov at openjdk.org  Mon Nov 20 16:25:28 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Nov 2023 16:25:28 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
Message-ID: <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>

On Mon, 20 Nov 2023 05:24:51 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 855:

> 853:         }
> 854:     }
> 855:     private int getXPosition(int column) {

This method is exactly the same as in `BasicTableUI`, if I don't miss anything.

You should rather move this to a utility class which is accessible to both `-UI` classes. Even more: if you're following the same code path that's implemented for `JTableHeader`, you should consider re-using the code from the header painting too? by extracting the relevant parts to a utility class if appropriate.

If another bug is found, it will need to be fixed in *one place* instead of several places which repeat the same code.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 57:

> 55:  */
> 56: 
> 57: public class JTableRightAlignmentTest {

As far as I understood from the description, it's about **Orientation**?left-to-right vs. right-to-left?rather than alignment.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 87:

> 85:             SwingUtilities.invokeAndWait(() -> {
> 86:                 int maxHeight = (int) (((double) table.table.getTableHeader().getHeight())
> 87:                         + ((double) table.table.getHeight()));

Why do you need to convert the height to `double`?

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 93:

> 91:                                 .getColumn(2)
> 92:                                 .getWidth() - 1;
> 93:                 Color expectedRGB = robot.getPixelColor(xPos, yPos);

I suggest capturing the screen rectangle and then sample the colours of the captured buffered image, or alternatively even paint into a buffered image.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 100:

> 98:                         saveImage(failImage, "failureImage.png");
> 99:                         passed = false;
> 100:                         failureString = "Test Failed at <" + xPos + ", " + y + ">";

`failureString == null` implies `passed` has the value `true` ? one variable / field is enough.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 144:

> 142:             "Salary",
> 143:     };
> 144:     List data = new ArrayList();

You should use generic `List<CustomTable.Data>` rather than raw one.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 157:

> 155:     }
> 156: 
> 157:     class Data {

It should be static. You can use a `record` for simplicity.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399424912
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399427167
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399431006
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399435563
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399441176
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399446461
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399449675

From honkar at openjdk.org  Mon Nov 20 18:02:12 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 20 Nov 2023 18:02:12 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
Message-ID: <bQ2u7kgQ_Z8TQKLyM0JwRTqrv7pNmmILK5dVGybXM_M=.c6401934-a55f-4c95-bdc8-31819bd0f46e@github.com>

On Fri, 10 Nov 2023 21:26:21 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It can be null if the NSApplication was created by code outside of AWT. Specifically, in the case of an FX or SWT toolkit, but in theory a native application using JAWT could do this.
>> 
>> In practice, since we haven't even seen a crash as a result of this, I doubt that this code is ever called if AWT isn't running the event loop and hasn't installed their delegate.
>
> To access any native code in AWT the app should initially init the LWCToolkit which sets that application delegate if it is not set already. Do we know how the FX can bypass that initialization?

@mrserb Shared delegate can be null if it is not installed when one of following conditions is met [ApplicationDelegate.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m#L118C4-L128C33) which is currently the case for Swing components embedded in FX window. 

With https://github.com/openjdk/jfx/pull/1280 JavaFX NSApp is no longer of type NSApp, it is of type NSAppFX and considering the scenario - Swing components embedded in FX window, we hit the case where sharedDelegate is null at places where null checks have been added.


BOOL shouldInstall = NO;
BOOL overrideDelegate = (getenv("AWT_OVERRIDE_NSDELEGATE") != NULL);
if (NSApp != nil) {
    if ([NSApp isMemberOfClass:[NSApplication class]] && overrideDelegate) shouldInstall = YES;
    if ([NSApp isKindOfClass:[NSApplicationAWT class]]) shouldInstall = YES;
}
checked = YES;
if (!shouldInstall) return nil;

sApplicationDelegate = [[ApplicationDelegate alloc] init];
return sApplicationDelegate;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1399559545

From prr at openjdk.org  Mon Nov 20 18:40:33 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Nov 2023 18:40:33 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v7]
In-Reply-To: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
Message-ID: <375g5CqMLrLiy3qX7ntQIUG4Rmomyqo9xrz8NWOAWYU=.c92ad36a-a12e-412b-817b-c10b9640d53f@github.com>

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

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

  8318364

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15476/files
  - new: https://git.openjdk.org/jdk/pull/15476/files/ee60f7e9..e435902d

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

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

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

From prr at openjdk.org  Mon Nov 20 18:40:41 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Nov 2023 18:40:41 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com>
Message-ID: <X-VNRdCFxNAKnGNLe4bcnLqed2K5Gqx4-5gUyRgoN-M=.36593c92-098a-47fc-8cce-77f83d575d72@github.com>

On Thu, 16 Nov 2023 13:48:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indentation
>
> src/java.desktop/share/classes/sun/font/HBShaper.java line 628:
> 
>> 626:         MemorySegment glyphInfoArr = glyphInfo.reinterpret(glyphInfoSize);
>> 627: 
>> 628:          for (int i=0; i<glyphCount; i++) {
> 
> Spacing between operators

fixed

> src/java.desktop/share/classes/sun/font/HBShaper.java line 658:
> 
>> 656:         startPt.x = advX;
>> 657:         startPt.y = advY;
>> 658:         startPt.x = advX;
> 
> duplicate assignment of startPt.x to advX...

fixed

> src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 167:
> 
>> 165:     }
>> 166: 
>> 167:     static boolean useFFM = true;
> 
> So, we want to enable FFM by default?

yes

> src/java.desktop/share/classes/sun/font/SunLayoutEngine.java line 184:
> 
>> 182:         FontStrike strike = font.getStrike(desc);
>> 183:         if (useFFM) {
>> 184:             java.lang.foreign.MemorySegment face = HBShaper.getFace(font);
> 
> Guess import at start will be more nicer...

ok .. although I do sometimes do this pattern when there's only one usage in the file.

> src/java.desktop/share/native/libfontmanager/HBShaper_Panama.c line 141:
> 
>> 139:      hb_buffer_destroy (buffer);
>> 140:      hb_font_destroy(hbfont);
>> 141:      if (features != NULL) free(features);
> 
> Guess coding style warrants braces { and next statement in separate line...

fixed

> src/java.desktop/share/native/libfontmanager/hb-jdk-font-p.cc line 238:
> 
>> 236:                       HBFloatToFixed(ptSize*devScale),
>> 237:                       HBFloatToFixed(ptSize*devScale));
>> 238:   return font;
> 
> indentation is off..

fixed

> test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 29:
> 
>> 27: /*
>> 28:    @test
>> 29:    @summary verify JNI and FFM harfbuzz OpenType layout implementations are equivalent.
> 
> bug id is missing

Because there isn't a "bug". It is just a test for new functionality.

> test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 45:
> 
>> 43: public class LayoutCompatTest {
>> 44: 
>> 45:    static String jni = "jni.txt";
> 
> Seems test is failing without fix with Exception in jtreg
> java.io.FileNotFoundException: jni.txt (The system cannot find the file specified)
> 
> Also in standalone mode. I was expecting it will fail with RuntimeException "files differ byte offset"

I'm not sure why it matters what this test does in a JDK without the fix, although logically, since the new system property isn't known, both cases would  end up using JNI, and I'd expect the test to pass. I am not sure why you say it should fail.

And I can't reproduce your first problem, I ran this test in jtreg on an unmodified JDK22 and it passed, as I expected, for the reason given above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399596923
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399597001
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399597224
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399597892
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399598026
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399598126
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399598208
PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399596012

From honkar at openjdk.org  Mon Nov 20 18:45:07 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 20 Nov 2023 18:45:07 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
 <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
Message-ID: <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>

On Fri, 10 Nov 2023 22:37:42 GMT, Phil Race <prr at openjdk.org> wrote:

>> In the case when AWT is embedded AWT does NOT start an  NSApplication and does not own it.
>> AWT overwriting FX's delegate, or any one else's is just plain wrong.
>> 
>> We can turn around what you said
>> "To access any native code in JavafX, the app should initialise GlassToolkit which sets its delegate, if not already set".
>> 
>> But you can't have both of these.
>> 
>> Meaning AWT isn't special here. It has to play by the same rules.
>> 
>> The toolkit that starts the NSApplication is the one that should be setting the delegate.
>> If you are embedded in someone else's application, it seems most logical that you defer to their application
>> and if this means some things aren't possible,  so be it.
>
>> Can you please provide details on how the delegate can be null here and there if it should be set at the startup of any awt application?
> 
> I commented on these in https://bugs.openjdk.org/browse/JDK-8319255 which is now closed as a dup.
> There I wrote (in part) 
> #######
> 
> I am not sure if these are all cases that can provably be in un-reachable code in the "nil" case, which
> means some embedded case. But if we ever do reach them, it seems we'd crash the app.
> And if we need to make the delegate "nil" in the non-subclassed NSApplication case (ie like FX)
> then we are more likely to cause a crash.
> 
> [list of places elided]
> 
> All these call sites need to be examined to understand that, and if necessary a test developed to
> confirm it.
> And even then, it might be prudent to add checks for nil.
> #####
> 
> So the request was to investigate and understand if they were needed, not just add them
> @honkar-jdk can comment on what she did there.

@prrace @kevinrushforth @mrserb 

The reason has to why we don't observe NPE or crash when sharedDelegate is null is because in Objective C when a method is called on a nil object it is treated as no-op and returns nil instead of NPE, contrary to what we would usually expect. Details [here](https://stackoverflow.com/questions/2696891/calling-a-method-on-an-uninitialized-object-null-pointer).

For example executing the following line when shared delegate is null and accessing defaultMenuBar on null delegate returns null and not NPE.

`[[ApplicationDelegate sharedDelegate] defaultMenuBar];`

Additionally we are not seeing any difference in defaultMenuBar with unpatched JDK + unpatched JFX (Non-Nil shared delegate) vs patched JDK + patched JFX (Nil shared delegate) at [AWTWindow.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m#L844) and [CMenubar.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuBar.m#L213)  because in both cases defaultMenuBar returned is nil. This might be the case at other places too and are being checked if they worked differently without and with this JDK patch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1399604866

From aivanov at openjdk.org  Mon Nov 20 20:04:15 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 20 Nov 2023 20:04:15 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
Message-ID: <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>

On Thu, 16 Nov 2023 05:19:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 66:

> 64:         try {
> 65:             // create test directory
> 66:             String tmpDir = System.getProperty("java.io.tmpdir");

This is the purpose of the [*scratch* directory in jtreg](https://openjdk.org/jtreg/faq.html#scratch-directory), and it's automatically [cleaned up after the test](https://openjdk.org/jtreg/writetests.html#cleanFiles): <q cite="https://openjdk.org/jtreg/writetests.html#cleanFiles">jtreg will automatically clean up any files written in the scratch directory.</q>

The test is designed for jtreg, so the simplest solution is *to use the current directory*.

If someone runs the test directly, without using jtreg, then it's their task to set up the current directory or clean up after the test.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 88:

> 86:                 testFile.mkdir();
> 87:             }
> 88:             testFile.deleteOnExit();

This is confusing: `testFile` is actually a directory.

You could improve the readability of the test by using methods: `createFoldersOnlyDir`, `createFilesOnlyDir`, `populateDirs`, `populateFiles` or something similar ? it would make the comments in the code unnecessary.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 98:

> 96:             }
> 97:         } catch (Exception e) {
> 98:             e.printStackTrace();

The exception should've been propagated: if an exception is thrown, test setup code has failed to prepare the expected environment ? the test would likely fail too, then let it fail quickly and report the real reason.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1399678519
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1399677679
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1399680175

From prr at openjdk.org  Mon Nov 20 20:06:24 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 20 Nov 2023 20:06:24 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v28]
In-Reply-To: <cwYJ5bZhQ7tYzhjkx7md6iYjN-_ly-miqc2lqQNJFsM=.7747870e-dde8-4533-a000-592ad650ffd9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <ntTXWoJHJ5051MsaEZg9KMGsxyfLWGENoJMH_MNJ28Q=.a22df483-9b34-490c-a8a7-fbe89fcb3a50@github.com>
 <7bKQMlhuI-R1N3nPYW-f-WrCPlk2u-7QfIzcmkPJkGE=.f0eb9f7b-5939-43ca-b58d-126310d49d0c@github.com>
 <cwYJ5bZhQ7tYzhjkx7md6iYjN-_ly-miqc2lqQNJFsM=.7747870e-dde8-4533-a000-592ad650ffd9@github.com>
Message-ID: <o14qk3yZOqFUhUgZaJaB5s26GUr5_xvnNQuK1WCi08M=.b9d33720-bbc6-4fb7-b253-3df1c1e7b4e4@github.com>

On Sat, 18 Nov 2023 13:59:34 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Canvas.cpp line 217:
>> 
>>> 215:         env->ExceptionClear();
>>> 216:         JNU_ThrowNullPointerException(env, "peer");
>>> 217:         env->DeleteGlobalRef(canvas);
>> 
>> you didn't code this up the way I did in my comment, which I think you should have done, and here you are deleting a ref to NULL, and the string passed to throw doesn't mention the canvas, which it can do unlike the old code.
>
> Sorry, I was trying to keep as close to the original code as possible. Woah, does that mean the original was bugged, since it was deleting a NULL canvas? Anyway, should I change the string to canvas or just keep it as "peer" like the original code does in that case?

Not buggy per se, since NULL is allowed
https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#deleteglobalref

But that doesn't make it good practice.

Yes, change the name because then it is more precise.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1399691542

From kcr at openjdk.org  Tue Nov 21 00:01:06 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Tue, 21 Nov 2023 00:01:06 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
 <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
 <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>
Message-ID: <GYl77levqVWWjHspziWqYk4F9ZT1KI_dE4pURDcwjeo=.935c7d09-ad4c-4cc3-aba8-49db69ac9fdd@github.com>

On Mon, 20 Nov 2023 18:41:37 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>>> Can you please provide details on how the delegate can be null here and there if it should be set at the startup of any awt application?
>> 
>> I commented on these in https://bugs.openjdk.org/browse/JDK-8319255 which is now closed as a dup.
>> There I wrote (in part) 
>> #######
>> 
>> I am not sure if these are all cases that can provably be in un-reachable code in the "nil" case, which
>> means some embedded case. But if we ever do reach them, it seems we'd crash the app.
>> And if we need to make the delegate "nil" in the non-subclassed NSApplication case (ie like FX)
>> then we are more likely to cause a crash.
>> 
>> [list of places elided]
>> 
>> All these call sites need to be examined to understand that, and if necessary a test developed to
>> confirm it.
>> And even then, it might be prudent to add checks for nil.
>> #####
>> 
>> So the request was to investigate and understand if they were needed, not just add them
>> @honkar-jdk can comment on what she did there.
>
> @prrace @kevinrushforth @mrserb 
> 
> The reason has to why we don't observe NPE or crash when sharedDelegate is null is because in Objective C when a method is called on a nil object it is treated as no-op and returns nil instead of NPE, contrary to what we would usually expect. Details [here](https://stackoverflow.com/questions/2696891/calling-a-method-on-an-uninitialized-object-null-pointer).
> 
> For example executing the following line when shared delegate is null and accessing defaultMenuBar on null delegate returns null and not NPE.
> 
> `[[ApplicationDelegate sharedDelegate] defaultMenuBar];`
> 
> Additionally we are not seeing any difference with defaultMenuBar case with unpatched JDK + unpatched JFX (Non-Nil shared delegate) vs patched JDK + patched JFX (Nil shared delegate) at [AWTWindow.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m#L844) and [CMenubar.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuBar.m#L213)  because in both cases defaultMenuBar returned is nil. This might be the case at other places too and are being checked if they worked differently without and with this JDK patch.

So in  either case -- with or without the delegate being overridden -- the defaultMenuBar is returning `nil`. This makes sense, since in the case of a JavaFX app, JavaFX has already initialized the `NSApplication` and set the system menu bar.

I do recommend leaving the `sharedDelegate` null checks that you added as part of this PR, since that way we short-circuit any other logic (e.g., in this specific case you avoid setting `isDisabled = NO` which seems more accurate), and you aren't relying on Objective C to treat this case as a no-op.

You might even consider making the `sharedDelegate` null check (and bailing out) earlier, but maybe there is a good reason to leave the check where it is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1399875074

From prr at openjdk.org  Tue Nov 21 00:05:12 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Nov 2023 00:05:12 GMT
Subject: RFR: 8320365: IPPrintService.getAttributes() causes blanket
 re-initialisation
Message-ID: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>

Whilst reviewing the fix for https://bugs.openjdk.org/browse/JDK-7001133 I realised that although the proposed
changes there may help, the problem would be inconsequential except that if anything causes an app to
call PrintService.getAttributes()  we will continually be re-initialising attributes, which causes IPPPrintService
to keep creating new instances of CUPSPrinter which are then discarded and over-written.
So update the implementation to only re-initialise the relevant attributes.

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

Commit messages:
 - 8320365

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

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

From psadhukhan at openjdk.org  Tue Nov 21 03:33:21 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Nov 2023 03:33:21 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v7]
In-Reply-To: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
Message-ID: <L2WADbyP9DHBQCeuuOUoKhzMvzEr9QfvPnpwVXeVhVM=.899cdd80-eb7c-4492-ae7a-ca9e8bbb0f6e@github.com>

> javadoc contract for JComponent.setMinimumSize(Dimension) states:
> 
> "Sets the minimum size of this component to a constant value. Subsequent calls to getMinimumSize will always return this value..."
> 
> However, JScrollBar overrides getMinimumSize() and breaks this contract - it always returns a minimum size derived from the preferred size even if you have previously called setMinimumSize()
> 
> Fix is made to check if mnimumSize is set and if so, honour it..

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

  Override set*Methods and update spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15325/files
  - new: https://git.openjdk.org/jdk/pull/15325/files/2733ea66..89aae1e2

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

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

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

From psadhukhan at openjdk.org  Tue Nov 21 03:42:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Nov 2023 03:42:12 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v7]
In-Reply-To: <375g5CqMLrLiy3qX7ntQIUG4Rmomyqo9xrz8NWOAWYU=.c92ad36a-a12e-412b-817b-c10b9640d53f@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <375g5CqMLrLiy3qX7ntQIUG4Rmomyqo9xrz8NWOAWYU=.c92ad36a-a12e-412b-817b-c10b9640d53f@github.com>
Message-ID: <sTpZgSFb-7AXeHduK_twNPPXxnNz1MOUmnZq04-A3qw=.bc96ff8a-e62a-429a-8422-28f72ea4650c@github.com>

On Mon, 20 Nov 2023 18:40:33 GMT, Phil Race <prr at openjdk.org> wrote:

>> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8318364

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15476#pullrequestreview-1741064594

From psadhukhan at openjdk.org  Tue Nov 21 03:42:15 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Nov 2023 03:42:15 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: <X-VNRdCFxNAKnGNLe4bcnLqed2K5Gqx4-5gUyRgoN-M=.36593c92-098a-47fc-8cce-77f83d575d72@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
 <gVzpFwdS4ppjxT8ahyYFLOgv58zpbB99Kf87IwzId4M=.38faff88-87ab-4eda-b815-6a60a7a6b8d3@github.com>
 <8tu4D5zX989IFr6DuSuReyYGd9Z-fOcmXcgePojFmvQ=.4dfbd237-f683-44fa-930d-fa89999b3242@github.com>
 <X-VNRdCFxNAKnGNLe4bcnLqed2K5Gqx4-5gUyRgoN-M=.36593c92-098a-47fc-8cce-77f83d575d72@github.com>
Message-ID: <D-vvbK0KXG7nNemB9hGtHdVh_BYPdimDiul1_1zaFj8=.73e7ee90-919e-4f57-a168-e034cedc3693@github.com>

On Mon, 20 Nov 2023 18:34:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/font/GlyphVector/LayoutCompatTest.java line 29:
>> 
>>> 27: /*
>>> 28:    @test
>>> 29:    @summary verify JNI and FFM harfbuzz OpenType layout implementations are equivalent.
>> 
>> bug id is missing
>
> Because there isn't a "bug". It is just a test for new functionality.

OK. I was thinking of somehow documenting 8318364 to link this new test against the enhancement..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1399990564

From psadhukhan at openjdk.org  Tue Nov 21 03:47:09 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Nov 2023 03:47:09 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <4uoJqnLaar5XxFo7DHAK6dlUrUvjbiSP7q6re1toGNk=.24206fc2-99cc-46b1-89f0-be14e79d9c3a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
 <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
 <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>
 <4uoJqnLaar5XxFo7DHAK6dlUrUvjbiSP7q6re1toGNk=.24206fc2-99cc-46b1-89f0-be14e79d9c3a@github.com>
Message-ID: <SLzsu5VDdIL6dCV970kdRHHJFK1aV9lk--2UcrRi7sc=.3920d0dc-c60d-42dd-9649-d4383f1b7800@github.com>

On Mon, 20 Nov 2023 11:14:21 GMT, Tejesh R <tr at openjdk.org> wrote:

> LTR doesn't need getXPosition

But it is called in `if (table.getComponentOrientation().isLeftToRight()) `condition above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399993460

From psadhukhan at openjdk.org  Tue Nov 21 03:47:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Nov 2023 03:47:11 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
Message-ID: <D1HAVqY7x6oOsilgofpfjvcuLzKzgADAZlkKgIWUzRw=.8f004831-f799-4c16-acb2-fdbd67b7cf84@github.com>

On Mon, 20 Nov 2023 10:08:42 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2102:
>> 
>>> 2100:                 cellRect = table.getCellRect(row, cMin, false);
>>> 2101:                 cellRect.x = getXPosition(cMax);
>>> 2102:                 for (int column = cMax; column >= cMin; column--) {
>> 
>> Is there any reason for choosing to paint from cMax to cMin ie from left-to-right in RTL orientation
>> when it was done from right-to-left before your fix? 
>> I guess painting from right-to-left also should work with cellRect.x -= columnWidth ie with no change in code, no?
>> 
>> One more q,
>> If there are 5 columns, then is it that for LTR cMin is 1, cMax 5 and for RTL cMin is 5 , cMax 1 or viceversa?
>
> Yes, we can either paint from right-to-left or from left-to-right. I followed `JTableHeader ` paint logic.  for 5 columns cMin = 0 and cMax = 4.

For both LTR and RTL?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399993561

From tr at openjdk.org  Tue Nov 21 03:51:06 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 03:51:06 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <D1HAVqY7x6oOsilgofpfjvcuLzKzgADAZlkKgIWUzRw=.8f004831-f799-4c16-acb2-fdbd67b7cf84@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <D1HAVqY7x6oOsilgofpfjvcuLzKzgADAZlkKgIWUzRw=.8f004831-f799-4c16-acb2-fdbd67b7cf84@github.com>
Message-ID: <BKU60xwBND18pAL8YEpMyxXWzbx1IvLIuJyfmzgziDw=.68645a26-d1d0-4720-8758-e7530e3f17c2@github.com>

On Tue, 21 Nov 2023 03:44:28 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yes, we can either paint from right-to-left or from left-to-right. I followed `JTableHeader ` paint logic.  for 5 columns cMin = 0 and cMax = 4.
>
> For both LTR and RTL?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1399995919

From tr at openjdk.org  Tue Nov 21 04:05:06 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 04:05:06 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <SLzsu5VDdIL6dCV970kdRHHJFK1aV9lk--2UcrRi7sc=.3920d0dc-c60d-42dd-9649-d4383f1b7800@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
 <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
 <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>
 <4uoJqnLaar5XxFo7DHAK6dlUrUvjbiSP7q6re1toGNk=.24206fc2-99cc-46b1-89f0-be14e79d9c3a@github.com>
 <SLzsu5VDdIL6dCV970kdRHHJFK1aV9lk--2UcrRi7sc=.3920d0dc-c60d-42dd-9649-d4383f1b7800@github.com>
Message-ID: <M2BeRHZbHDaWC78Eg0DAwudj86_EgHvhmoZIe5r-hsI=.95e3990a-55fd-4d66-b551-6ed36bc9cd84@github.com>

On Tue, 21 Nov 2023 03:44:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> LTR rendering will work unless the Table is fully occupied w.r.t the Panel. Here the Max width of each column is set which is less than the Panel size where extra space would be there on left side of the Table. LTR doesn't need getXPosition because it'll always be 0/attached to Panel at left position. In JTableHeader [r.x](https://github.com/openjdk/jdk/blob/6c5e15c1a291ca5ba1e4c3a90351bc71665ce988/src/java.desktop/share/classes/javax/swing/table/JTableHeader.java#L399) is computed on this offset basis.
>
>> LTR doesn't need getXPosition
> 
> But it is called in `if (table.getComponentOrientation().isLeftToRight()) `condition above

Yes, actually it is not required because it gives/should give the same x position value. Have to remove it, might have added for checking if it had any effect on LTR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400002281

From tr at openjdk.org  Tue Nov 21 04:16:08 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 04:16:08 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
Message-ID: <jiLLA4tlIHYzAGiVYelmS6bJVvClEXNb6E4bv4O4bw4=.edfd1325-35e6-46fb-b625-b19c1019297e@github.com>

On Mon, 20 Nov 2023 16:07:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 57:
> 
>> 55:  */
>> 56: 
>> 57: public class JTableRightAlignmentTest {
> 
> As far as I understood from the description, it's about **Orientation**?left-to-right vs. right-to-left?rather than alignment.

<img width="719" alt="JTableRTLOrientationFix" src="https://github.com/openjdk/jdk/assets/94159358/3de732e6-cab6-4bb0-8c25-724fac22eced">

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400007130

From tr at openjdk.org  Tue Nov 21 04:56:10 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 04:56:10 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
Message-ID: <Vkty-v1al8wl6g6VWjiqeYIKrs041k82EW63fx3Qfmc=.68f15da2-1f2f-4cbf-83e0-658436012938@github.com>

On Mon, 20 Nov 2023 16:06:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 855:
> 
>> 853:         }
>> 854:     }
>> 855:     private int getXPosition(int column) {
> 
> This method is exactly the same as in `BasicTableUI`, if I don't miss anything.
> 
> You should rather move this to a utility class which is accessible to both `-UI` classes. Even more: if you're following the same code path that's implemented for `JTableHeader`, you should consider re-using the code from the header painting too? by extracting the relevant parts to a utility class if appropriate.
> 
> If another bug is found, it will need to be fixed in *one place* instead of several places which repeat the same code.

The methods can be both moved to Utility class for sure, but not sure of re-using the code from `JTableHeader` coz `getColumnModel()` and `getWidthInRightToLeft()` are specific to it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400026457

From jwaters at openjdk.org  Tue Nov 21 06:45:42 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 06:45:42 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v29]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <dbh9hxp6IBuA5N3VAWucZlOtclW_PQUg0g1nHch1hSo=.93c156a2-9f4c-4b73-8ef8-31e806a0eabd@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Fixup awt_Canvas.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/a9dc87f2..523ea9e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=27-28

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

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

From jwaters at openjdk.org  Tue Nov 21 06:45:44 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 06:45:44 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v28]
In-Reply-To: <o14qk3yZOqFUhUgZaJaB5s26GUr5_xvnNQuK1WCi08M=.b9d33720-bbc6-4fb7-b253-3df1c1e7b4e4@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <ntTXWoJHJ5051MsaEZg9KMGsxyfLWGENoJMH_MNJ28Q=.a22df483-9b34-490c-a8a7-fbe89fcb3a50@github.com>
 <7bKQMlhuI-R1N3nPYW-f-WrCPlk2u-7QfIzcmkPJkGE=.f0eb9f7b-5939-43ca-b58d-126310d49d0c@github.com>
 <cwYJ5bZhQ7tYzhjkx7md6iYjN-_ly-miqc2lqQNJFsM=.7747870e-dde8-4533-a000-592ad650ffd9@github.com>
 <o14qk3yZOqFUhUgZaJaB5s26GUr5_xvnNQuK1WCi08M=.b9d33720-bbc6-4fb7-b253-3df1c1e7b4e4@github.com>
Message-ID: <v8u-E1SUKjuqVHPuKnit1sPydklNK1s4VbH4Rrc9oJ8=.c7d3aa6e-da00-4d43-bf6a-f00a247dd7c2@github.com>

On Mon, 20 Nov 2023 20:03:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Sorry, I was trying to keep as close to the original code as possible. Woah, does that mean the original was bugged, since it was deleting a NULL canvas? Anyway, should I change the string to canvas or just keep it as "peer" like the original code does in that case?
>
> Not buggy per se, since NULL is allowed
> https://docs.oracle.com/en/java/javase/21/docs/specs/jni/functions.html#deleteglobalref
> 
> But that doesn't make it good practice.
> 
> Yes, change the name because then it is more precise.

Is the new code better?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1400090582

From tr at openjdk.org  Tue Nov 21 06:51:12 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 06:51:12 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
Message-ID: <bKRDx0lsm-kMnKeI5A4F_EN_mqvcspCC5jpAnKVglV0=.5cd843c6-591c-451f-b018-8d41a7bb2d94@github.com>

On Mon, 20 Nov 2023 16:11:53 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 93:
> 
>> 91:                                 .getColumn(2)
>> 92:                                 .getWidth() - 1;
>> 93:                 Color expectedRGB = robot.getPixelColor(xPos, yPos);
> 
> I suggest capturing the screen rectangle and then sample the colours of the captured buffered image, or alternatively even paint into a buffered image.

Any particular reason for this suggestion ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400095288

From jwaters at openjdk.org  Tue Nov 21 06:55:58 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 06:55:58 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v30]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <SVcWWmzJO64UTb4GnGle2hqxg7rehH6_0ah7FM2ZFYQ=.4968d9ec-d89b-4292-8497-412bc22d0971@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Comment awt_DnDDT.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/523ea9e6..7a581f58

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=28-29

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

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

From jwaters at openjdk.org  Tue Nov 21 07:16:35 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 07:16:35 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v31]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <s366EvuHtuKMm9AnXfpW6_eb4S4YqKUkMJ9F4l53IYk=.74515e39-10a4-4aff-9153-b09aa8ec3640@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Change awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/7a581f58..88947ad0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=29-30

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

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

From jwaters at openjdk.org  Tue Nov 21 07:20:55 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 07:20:55 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v32]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <SOqe39Av85SKrjid41a_IU7c-eEBgmhdvR9RnBJD7HM=.c5c00355-6e0b-4a16-90d1-5a664534031c@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/88947ad0..296df528

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=30-31

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

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

From jwaters at openjdk.org  Tue Nov 21 07:32:43 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 07:32:43 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v33]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <QAYtqu638zuO1eJsvm5k3wNzNA5YEJGzu8jtMZit_tw=.e29ef365-eb77-4a94-89de-bb07ee4cf631@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Convert more in awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/296df528..5b4321b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=31-32

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

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

From jwaters at openjdk.org  Tue Nov 21 07:39:36 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 07:39:36 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v34]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <M_bdFI4mIKCJ0qnMkDDMHIBo_IJPIjrn3qbvWvVbhXo=.39c72cdc-5f6b-45ed-ba22-5eb13e40a1f3@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Even more changes awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/5b4321b8..a59574fd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=33
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=32-33

  Stats: 27 lines in 1 file changed: 17 ins; 6 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096

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

From jwaters at openjdk.org  Tue Nov 21 07:55:40 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 07:55:40 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v35]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <hksNVwRAxDjNCT2oQkm5eNxf_n7l8ZOu9Te3qXBIBXc=.9d45e5e7-cbe2-46d5-9758-fd1a2fff6471@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Even even more changes awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/a59574fd..6138af4a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=33-34

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

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

From psadhukhan at openjdk.org  Tue Nov 21 08:13:07 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 21 Nov 2023 08:13:07 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <M2BeRHZbHDaWC78Eg0DAwudj86_EgHvhmoZIe5r-hsI=.95e3990a-55fd-4d66-b551-6ed36bc9cd84@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
 <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
 <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>
 <4uoJqnLaar5XxFo7DHAK6dlUrUvjbiSP7q6re1toGNk=.24206fc2-99cc-46b1-89f0-be14e79d9c3a@github.com>
 <SLzsu5VDdIL6dCV970kdRHHJFK1aV9lk--2UcrRi7sc=.3920d0dc-c60d-42dd-9649-d4383f1b7800@github.com>
 <M2BeRHZbHDaWC78Eg0DAwudj86_EgHvhmoZIe5r-hsI=.95e3990a-55fd-4d66-b551-6ed36bc9cd84@github.com>
Message-ID: <gEumn-KIciE0L5n8OCgf5CQ9DAYBGsuX9BkPPseQRnI=.6e375e58-741c-40ef-850e-a12f246ec862@github.com>

On Tue, 21 Nov 2023 04:02:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> LTR doesn't need getXPosition
>> 
>> But it is called in `if (table.getComponentOrientation().isLeftToRight()) `condition above
>
> Yes, actually it is not required because it gives/should give the same x position value. Have to remove it, might have added for checking if it had any effect on LTR.

I guess you can simplify the fix without using `getXPosition`..You probably would still need `getWidthInRIghtToLeft` but as suggested, having an unified method in a common class like SwingUtilities2 is desirable...Let me know if this will work..


--- a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java
+++ b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java
@@ -2028,9 +2028,19 @@ private void paintGrid(Graphics g, int rMin, int rMax, int cMin, int cMax) {
         if (table.getShowHorizontalLines()) {
             int tableWidth = damagedArea.x + damagedArea.width;
             int y = damagedArea.y;
-            for (int row = rMin; row <= rMax; row++) {
-                y += table.getRowHeight(row);
-                SwingUtilities2.drawHLine(g, damagedArea.x, tableWidth - 1, y - 1);
+            if (table.getComponentOrientation().isLeftToRight()) {
+                for (int row = rMin; row <= rMax; row++) {
+                    y += table.getRowHeight(row);
+                    SwingUtilities2.drawHLine(g, damagedArea.x, tableWidth - 1, y - 1);
+                }
+            } else {
+                TableColumnModel cm = table.getColumnModel();
+                for (int row = rMax; row >= rMin; row--) {
+                    y += table.getRowHeight(row);
+                    int w = cm.getColumn(cMax).getWidth();
+                    damagedArea.x = table.getWidth() - (w * (cMax + 1));
+                    SwingUtilities2.drawHLine(g, damagedArea.x, table.getWidth() - 1, y - 1);
+                }
             }
         }
         if (table.getShowVerticalLines()) {
@@ -2090,18 +2100,12 @@ private void paintCells(Graphics g, int rMin, int rMax, int cMin, int cMax) {
             }
         } else {
             for(int row = rMin; row <= rMax; row++) {
-                cellRect = table.getCellRect(row, cMin, false);
-                aColumn = cm.getColumn(cMin);
-                if (aColumn != draggedColumn) {
-                    columnWidth = aColumn.getWidth();
-                    cellRect.width = columnWidth - columnMargin;
-                    paintCell(g, cellRect, row, cMin);
-                }
-                for(int column = cMin+1; column <= cMax; column++) {
+                for(int column = cMin; column <= cMax; column++) {
+                    cellRect = table.getCellRect(row, column, false);
                     aColumn = cm.getColumn(column);
                     columnWidth = aColumn.getWidth();
                     cellRect.width = columnWidth - columnMargin;
-                    cellRect.x -= columnWidth;
+                    cellRect.x = table.getWidth() - (columnWidth * (column + 1));
                     if (aColumn != draggedColumn) {
                         paintCell(g, cellRect, row, column);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400168991

From duke at openjdk.org  Tue Nov 21 08:40:40 2023
From: duke at openjdk.org (songpv-imt)
Date: Tue, 21 Nov 2023 08:40:40 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v7]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com>

> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
> 
> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)

songpv-imt has updated the pull request incrementally with one additional commit since the last revision:

  Update InterJVMGetDropSuccessTest.java
  Instead of using SYNC_LOCK to synchronize accessing the listener's fields, for better code transparency, we have placed the code that accesses the listener's fields from the main thread into the AWT Event Queue.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16396/files
  - new: https://git.openjdk.org/jdk/pull/16396/files/eb667f4e..9a9c3112

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

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

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

From duke at openjdk.org  Tue Nov 21 08:40:41 2023
From: duke at openjdk.org (songpv-imt)
Date: Tue, 21 Nov 2023 08:40:41 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v6]
In-Reply-To: <FyVlQDMdF7tji0yw8dEUI9VMRaqayYv0qhvmth_VywQ=.09f4d384-5deb-4c73-82df-7288707d28d2@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <FyVlQDMdF7tji0yw8dEUI9VMRaqayYv0qhvmth_VywQ=.09f4d384-5deb-4c73-82df-7288707d28d2@github.com>
Message-ID: <8pVL-HXwf1kF_TQ3NxX5O0qwoxW9OahYK9sXwMGYZqc=.b1cb415c-500d-4939-b94d-2808a7847649@github.com>

On Wed, 8 Nov 2023 09:28:13 GMT, songpv-imt <duke at openjdk.org> wrote:

>> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
>> 
>> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)
>
> songpv-imt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterJVMGetDropSuccessTest.java
>   Change BUTTON1_MASK to BUTTON1_DOWN_MASK because BUTTON1_MASK is deprecated: https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/event/InputEvent.html#BUTTON1_MASK

Hmm... Are you suggesting instead of using SYNC_LOCK, for better code transparency, we should place the code that accesses the listener's fields from the main thread into AWT Event Queue with EventQueue.invokeAndWait? Can you please check if the update code meets your suggestion? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1820460444

From abhiscxk at openjdk.org  Tue Nov 21 08:42:43 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 08:42:43 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v4]
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <VmdwpwlLawjlKVPcFYL5k4dXJyqbw-vNiD12kU1VtYU=.9c27975c-aaa8-43f6-b269-4fad7b0361d1@github.com>

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16467/files
  - new: https://git.openjdk.org/jdk/pull/16467/files/7f1b1eaa..ee48ccda

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

  Stats: 43 lines in 1 file changed: 16 ins; 19 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16467.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16467/head:pull/16467

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

From abhiscxk at openjdk.org  Tue Nov 21 08:42:45 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 08:42:45 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v3]
In-Reply-To: <T8e5aDDEDNSIqlN5Sc5PNUilTc3PvNvJi8wQkJxrckQ=.d679d743-a29f-4df3-890c-9c587ca5d59f@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>
 <T8e5aDDEDNSIqlN5Sc5PNUilTc3PvNvJi8wQkJxrckQ=.d679d743-a29f-4df3-890c-9c587ca5d59f@github.com>
Message-ID: <XfLCsSvxaUNuQnKKWfgyVEi5pq0yKSGnROsUdfUDBpw=.90902db2-66f5-46a0-bf88-a996493ce688@github.com>

On Mon, 20 Nov 2023 14:22:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor fix
>
> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 33:
> 
>> 31:  *          painting is set to false
>> 32:  * @run main TestProgressBarBorder
>> 33:  */
> 
> Could you move the tags closer to the class declaration, after the imports, please?
> 
> When the tags are before the class, they're not collapsed along with the copyright header when viewed in an IDE, which makes them easily visible.

Updated.

> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 51:
> 
>> 49:     private static volatile boolean isImgEqual;
>> 50:     private static BufferedImage borderPaintedImg;
>> 51:     private static BufferedImage borderNotPaintedImg;
> 
> All these could be local variables.

`boolean` variable is changed to local variable. Others are used in EDT and other method, so kept it as class variables.

> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 63:
> 
>> 61:                 setLookAndFeel(laf);
>> 62:                 createAndShowUI();
>> 63:             });
> 
> Do everything on EDT or don't bother with EDT: mixing it in this way isn't good.
> 
> In this case, it's safe to call the methods you use on the main thread. However, I heard that there's a convention to run all the code on EDT. Whatever you choose? but at least don't mix the threads.

Updated.

> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 67:
> 
>> 65:             borderPaintedImg = paintToImage(progressBar);
>> 66:             progressBar.setBorderPainted(false);
>> 67:             borderNotPaintedImg = paintToImage(progressBar);
> 
> ~~You may want to call `progressBar.setBorderPainted(true)` explicitly?this way the test will not depend on the default value. If whatever reason the default value changes, the test will become useless? it will be testing with `isBorderPainted == false` in both cases.~~
> You're setting it in `createAndShowUI`; I still think it's better to move the call to `progressBar.setBorderPainted(true)` here.
> 
> Aren't `withBorder` and `withoutBorder` more succinct names?

Updated.

> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 93:
> 
>> 91:         progressBar = new JProgressBar();
>> 92:         progressBar.setSize(100, 50);
>> 93:         // set initial value
> 
> The comment is redundant, isn't it?

Yeah.. updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400199006
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400202704
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400202971
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400198329
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400197734

From abhiscxk at openjdk.org  Tue Nov 21 08:42:45 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 08:42:45 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <JA44zEvaZWFx91FMstOaSSN_Km0Pwsy3qXDAD_ANmL0=.17b6acb4-7c55-43f7-a802-8eb66f1c650c@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <dp2SajUlqqSR5yMsvPCi_Bf6LZZBcBPPMz2ta1Dx4jY=.f1ac9324-11e9-48bd-ac69-a0fb276b6865@github.com>
 <o-bxcNcM3q3Vq4TjcqP_6HE52QUAM3dWqLqkgC18DY4=.50aebe20-b728-4f9d-b52f-55a54469d6bf@github.com>
 <f7X5cjFhVBKQBMkFBqyIzwwCedv0gOoXvbPGdbQx90g=.00e80aa4-3e1b-462e-a809-e0fc284c6a63@github.com>
 <JA44zEvaZWFx91FMstOaSSN_Km0Pwsy3qXDAD_ANmL0=.17b6acb4-7c55-43f7-a802-8eb66f1c650c@github.com>
Message-ID: <41PztaNEjHA34v022i73Jt3XV2mXV6JBq2n7IG_ZP0E=.086abb23-1811-4e36-b1f6-4e36886208cd@github.com>

On Mon, 20 Nov 2023 14:39:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Updated to `isImgEqual`.
>
> Grammatically, it should be `areImgsEqual` or `areImagesEqual`.
> 
> Would `boolean equal = Util.compareBufferedImages` be enough to convey the meaning?

Yeah, equal should be ok.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400200483

From tr at openjdk.org  Tue Nov 21 09:57:08 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 09:57:08 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <gEumn-KIciE0L5n8OCgf5CQ9DAYBGsuX9BkPPseQRnI=.6e375e58-741c-40ef-850e-a12f246ec862@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
 <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
 <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>
 <4uoJqnLaar5XxFo7DHAK6dlUrUvjbiSP7q6re1toGNk=.24206fc2-99cc-46b1-89f0-be14e79d9c3a@github.com>
 <SLzsu5VDdIL6dCV970kdRHHJFK1aV9lk--2UcrRi7sc=.3920d0dc-c60d-42dd-9649-d4383f1b7800@github.com>
 <M2BeRHZbHDaWC78Eg0DAwudj86_EgHvhmoZIe5r-hsI=.95e3990a-55fd-4d66-b551-6ed36bc9cd84@github.com>
 <gEumn-KIciE0L5n8OCgf5CQ9DAYBGsuX9Bk
 PPseQRnI=.6e375e58-741c-40ef-850e-a12f246ec862@github.com>
Message-ID: <5BjD3cFjGK_T7GZqezXREiQE5x6SG3Nq11jRmC_U_m8=.15cea85e-bce6-40bb-be78-a6836ea15e90@github.com>

On Tue, 21 Nov 2023 08:10:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yes, actually it is not required because it gives/should give the same x position value. Have to remove it, might have added for checking if it had any effect on LTR.
>
> I guess you can simplify the fix without using `getXPosition`..You probably would still need `getWidthInRIghtToLeft` but as suggested, having an unified method in a common class like SwingUtilities2 is desirable...Let me know if this will work..
> 
> 
> --- a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java
> +++ b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java
> @@ -2028,9 +2028,19 @@ private void paintGrid(Graphics g, int rMin, int rMax, int cMin, int cMax) {
>          if (table.getShowHorizontalLines()) {
>              int tableWidth = damagedArea.x + damagedArea.width;
>              int y = damagedArea.y;
> -            for (int row = rMin; row <= rMax; row++) {
> -                y += table.getRowHeight(row);
> -                SwingUtilities2.drawHLine(g, damagedArea.x, tableWidth - 1, y - 1);
> +            if (table.getComponentOrientation().isLeftToRight()) {
> +                for (int row = rMin; row <= rMax; row++) {
> +                    y += table.getRowHeight(row);
> +                    SwingUtilities2.drawHLine(g, damagedArea.x, tableWidth - 1, y - 1);
> +                }
> +            } else {
> +                TableColumnModel cm = table.getColumnModel();
> +                for (int row = rMax; row >= rMin; row--) {
> +                    y += table.getRowHeight(row);
> +                    int w = cm.getColumn(cMax).getWidth();
> +                    damagedArea.x = table.getWidth() - (w * (cMax + 1));
> +                    SwingUtilities2.drawHLine(g, damagedArea.x, table.getWidth() - 1, y - 1);
> +                }
>              }
>          }
>          if (table.getShowVerticalLines()) {
> @@ -2090,18 +2100,12 @@ private void paintCells(Graphics g, int rMin, int rMax, int cMin, int cMax) {
>              }
>          } else {
>              for(int row = rMin; row <= rMax; row++) {
> -                cellRect = table.getCellRect(row, cMin, false);
> -                aColumn = cm.getColumn(cMin);
> -                if (aColumn != draggedColumn) {
> -                    columnWidth = aColumn.getWidth();
> -                    cellRect.width = columnWidth - columnMargin;
> -                    paintCell(g, cellRect, row, cMin);
> -                }
> -                for(int column = cMin+1; column <= cMax; column++) {
> +                for(int column = cMin; column <= cMax; column++) {
> +                    cellRect = table.getCellRect(row, column, false);
>                      aColumn = cm.getColumn(column);
>                      columnWidth = aColumn.getWid...

Sure, anyhow I'm moving common methods to `SwingUtilities2 `now and testing...... Will check if your suggestions works fine and let u know...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400308541

From jwaters at openjdk.org  Tue Nov 21 11:03:50 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 11:03:50 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v36]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <ox5-PBPi8WKaV7yhbNTWwKyYqYT3qWv-3HtxvjFNGyc=.4cf96a8f-7a58-438d-8045-96189039d56d@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  gis in awt_Component.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/6138af4a..becdf84c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=34-35

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

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

From jwaters at openjdk.org  Tue Nov 21 11:15:46 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 11:15:46 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v37]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <m5TUH11c9ywtpk05sJCK_lExkd3wt9HzBBj6GfKhEjQ=.f4b9c030-d859-4016-95b9-28363cc069df@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  awt_Frame.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/becdf84c..d486dc82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=36
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=35-36

  Stats: 22 lines in 1 file changed: 12 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096

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

From jwaters at openjdk.org  Tue Nov 21 11:19:35 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 21 Nov 2023 11:19:35 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v38]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <qFRQzzrAznn-bdXuL_Lnq3W9d8tfCNjjL4kJwS6XLz8=.4e762fcd-9a26-4a37-bd9b-f29d2f79c513@github.com>

> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.

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

  Whitespace awt_Component.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/d486dc82..b9a7e02e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=37
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=36-37

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

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

From tr at openjdk.org  Tue Nov 21 12:06:42 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 12:06:42 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <gEumn-KIciE0L5n8OCgf5CQ9DAYBGsuX9BkPPseQRnI=.6e375e58-741c-40ef-850e-a12f246ec862@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <jjoq7M1enQt1bGspYnhxtghmq0FasMjE0qb4_VapO0I=.ca0c1e9e-c35a-4235-bd3d-4d68a2c41e7b@github.com>
 <qakiZf0c9RzDRavRYp7ejczRG1i0be4k-ArcmS5y4AQ=.e953d2b7-8e0c-429c-9625-2c0150ac3fbc@github.com>
 <0tE0m-9tnfzq86aHln27AC_i7sRsr9xWoIWeT7Bq5ac=.98a177fa-a49d-4819-ba57-a38330297656@github.com>
 <kfyjMgcjAtu1oeIkOWM_YFGXhsT8mRQARf6N9tI8UW8=.33a28269-ec3b-4c2b-938d-3e444718f6bb@github.com>
 <c4DRpgNhGg8a45sm4Gi8adZzL19DErSXMg4a77DPO2g=.c3fe6a7c-76d4-44e8-91b0-b00433eed039@github.com>
 <4uoJqnLaar5XxFo7DHAK6dlUrUvjbiSP7q6re1toGNk=.24206fc2-99cc-46b1-89f0-be14e79d9c3a@github.com>
 <SLzsu5VDdIL6dCV970kdRHHJFK1aV9lk--2UcrRi7sc=.3920d0dc-c60d-42dd-9649-d4383f1b7800@github.com>
 <M2BeRHZbHDaWC78Eg0DAwudj86_EgHvhmoZIe5r-hsI=.95e3990a-55fd-4d66-b551-6ed36bc9cd84@github.com>
 <gEumn-KIciE0L5n8OCgf5CQ9DAYBGsuX9Bk
 PPseQRnI=.6e375e58-741c-40ef-850e-a12f246ec862@github.com>
Message-ID: <BP97k5I70Cm54oCsBeI3tyYqHn_RUWddwBbaQ6xn0N8=.966e7f66-4d44-4552-9fc2-cf5b8ec75d5a@github.com>

On Tue, 21 Nov 2023 08:10:43 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Yes, actually it is not required because it gives/should give the same x position value. Have to remove it, might have added for checking if it had any effect on LTR.
>
> I guess you can simplify the fix without using `getXPosition`..You probably would still need `getWidthInRIghtToLeft` but as suggested, having an unified method in a common class like SwingUtilities2 is desirable...Let me know if this will work..
> 
> 
> --- a/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java
> +++ b/src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java
> @@ -2028,9 +2028,19 @@ private void paintGrid(Graphics g, int rMin, int rMax, int cMin, int cMax) {
>          if (table.getShowHorizontalLines()) {
>              int tableWidth = damagedArea.x + damagedArea.width;
>              int y = damagedArea.y;
> -            for (int row = rMin; row <= rMax; row++) {
> -                y += table.getRowHeight(row);
> -                SwingUtilities2.drawHLine(g, damagedArea.x, tableWidth - 1, y - 1);
> +            if (table.getComponentOrientation().isLeftToRight()) {
> +                for (int row = rMin; row <= rMax; row++) {
> +                    y += table.getRowHeight(row);
> +                    SwingUtilities2.drawHLine(g, damagedArea.x, tableWidth - 1, y - 1);
> +                }
> +            } else {
> +                TableColumnModel cm = table.getColumnModel();
> +                for (int row = rMax; row >= rMin; row--) {
> +                    y += table.getRowHeight(row);
> +                    int w = cm.getColumn(cMax).getWidth();
> +                    damagedArea.x = table.getWidth() - (w * (cMax + 1));
> +                    SwingUtilities2.drawHLine(g, damagedArea.x, table.getWidth() - 1, y - 1);
> +                }
>              }
>          }
>          if (table.getShowVerticalLines()) {
> @@ -2090,18 +2100,12 @@ private void paintCells(Graphics g, int rMin, int rMax, int cMin, int cMax) {
>              }
>          } else {
>              for(int row = rMin; row <= rMax; row++) {
> -                cellRect = table.getCellRect(row, cMin, false);
> -                aColumn = cm.getColumn(cMin);
> -                if (aColumn != draggedColumn) {
> -                    columnWidth = aColumn.getWidth();
> -                    cellRect.width = columnWidth - columnMargin;
> -                    paintCell(g, cellRect, row, cMin);
> -                }
> -                for(int column = cMin+1; column <= cMax; column++) {
> +                for(int column = cMin; column <= cMax; column++) {
> +                    cellRect = table.getCellRect(row, column, false);
>                      aColumn = cm.getColumn(column);
>                      columnWidth = aColumn.getWid...

@prsadhuk Its working if the width of all columns are equal, and doesn't work if we have varying column width.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400468714

From tr at openjdk.org  Tue Nov 21 12:06:44 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 12:06:44 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <vY5L6B6JthT0t41NATp_atUu22sTOte-ln7gdbbQob4=.7c09d906-5b17-44ad-b117-ab9971f3544f@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <EelAtNWtkEt7-vdrk6KZLUIo6aXWLwbuKA6Mial3yU4=.becda19e-79c6-4962-83ad-8816d0387665@github.com>
 <ros7dIzLkKD39TTO0j03P1-dtr3SYomuaxODIL-fk9E=.c23d8523-e9f9-4ded-b668-822f0fe73323@github.com>
 <QmhD0ufNRAe_tImCxBt9WXEl7FXA8a1DL_NQvdkzZ4k=.dd1ce152-ac61-4b3e-b0d8-6ea7499ad7a0@github.com>
 <MiYDc9ORzI27_NlKNO4RiTtNz5Pys2W13ChbsmMBGJI=.bc1677ce-5283-4780-b911-f218d1d05d80@github.com>
 <7zfCJtwbOxHNgMUjFftwjvXwx_ktjDWBDvVP_Bmco64=.2c57604f-ccf6-4455-ad90-4c919bb34fb5@github.com>
 <S_eW_y5oHOip-c10NZEszQloUxYB9Ij8DZYb0E1SPps=.321499f5-c60b-4864-a062-d8a3bf614847@github.com>
 <vY5L6B6JthT0t41NATp_atUu22sTOte-ln7gdbbQob4=.7c09d906-5b17-44ad-b117-ab9971f3544f@github.com>
Message-ID: <-5u1SHE-085ab0ONdXtjBmKLLn-qt1sVUcRbIwLT1qQ=.3db43f30-9a01-4d33-b670-d9b2e7f594cb@github.com>

On Mon, 20 Nov 2023 15:50:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> But the current logic in test doesn't hold good for few Look and Feel including Nimbus. Should I make the test as manual mentioning it to be tested against all Look and Feel?
>
> You can have two tests: for Metal and for Synth (Nimbus).
> 
> A manual test is an option too, but if you can automate each separate L&F, you should definitely do it: an automatic test will be run regularly and often.

I have modified the test and now it can be tested for all Look and Feel.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400472354

From tr at openjdk.org  Tue Nov 21 12:06:41 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 12:06:41 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/6e25fb36..10b199bf

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

  Stats: 217 lines in 4 files changed: 77 ins; 99 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/16374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16374/head:pull/16374

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

From aivanov at openjdk.org  Tue Nov 21 14:11:15 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 14:11:15 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v3]
In-Reply-To: <CPIiUNpDS0fTvULhPl_ibsJlkONTXevFQYIEq5-e8yU=.8aec4739-e1c8-460d-8300-482cd298c352@github.com>
References: <ZsMXtiW2DnayIHuAemRjnYqKYJf1T0-sYT7KBwRP7v8=.d7948ddf-cb2e-482d-8d85-cdce763b2aa2@github.com>
 <CPIiUNpDS0fTvULhPl_ibsJlkONTXevFQYIEq5-e8yU=.8aec4739-e1c8-460d-8300-482cd298c352@github.com>
Message-ID: <3QQGijNyprMJBC8JrdntzeD5RKklMDkZB60_BPC-2dw=.a1b6c3e9-1f3d-4010-933f-23d9c2375fdd@github.com>

On Thu, 2 Nov 2023 23:25:31 GMT, ScientificWare <duke at openjdk.org> wrote:

>> This is referenced in Java Bug Database as
>> - [JDK-8314731 : Adds support for the alt attribute in the image type input HTML tag.](https://bugs.java.com/bugdatabase/view_bug?bug_id=8314731)
>> 
>> This is tracked in JBS as
>> - [JDK-8314731 : Add support for the alt attribute in the image type input HTML tag](https://bugs.openjdk.java.net/browse/JDK-8314731)
>> 
>> According [HTML 3.2 specification](https://www.w3.org/TR/2018/SPSD-html32-20180315/#input)
>> 
>> `alt` is not an attribute of the `input` element.
>> 
>> According [HTML 4.01 specifications](https://www.w3.org/TR/html4/interact/forms.html#h-17.4) : 
>> 
>>> ... For accessibility reasons, authors should provide [alternate text](https://www.w3.org/TR/html4/struct/objects.html#alternate-text) for the image via the [alt](https://www.w3.org/TR/html4/struct/objects.html#adef-alt) attribute. ...
>> 
>> This feature is not implemented in `FormView.java`.
>> 
>> ??  ~~This also affects the HTML 32 DTD~~
>> 
>> ![Screenshot_20230817_025316](https://github.com/openjdk/jdk/assets/19194678/8e580574-d842-4a65-884b-26e33cd12138)
>> 
>> Left before the patch and right after the patch.
>> 
>> 
>> import java.awt.BorderLayout;
>> import java.awt.Dimension;
>> import javax.swing.JEditorPane;
>> import javax.swing.JFrame;
>> import javax.swing.JScrollPane;
>> import javax.swing.SwingUtilities;
>> import javax.swing.text.Document;
>> import javax.swing.text.html.HTMLEditorKit;
>> import javax.swing.text.html.StyleSheet;
>> 
>> public class HTMLAddsSupportAltInputTag {
>>   public static void main(String[] args) {
>>     new HTMLAddsSupportAltInputTag();
>>   }
>>   
>>   public HTMLAddsSupportAltInputTag() {
>>     SwingUtilities.invokeLater(new Runnable(){
>>       public void run(){
>>         JEditorPane jEditorPane = new JEditorPane();
>>         jEditorPane.setEditable(false);
>>         JScrollPane scrollPane = new JScrollPane(jEditorPane);
>>         HTMLEditorKit kit = new HTMLEditorKit();
>>         jEditorPane.setEditorKit(kit);
>>         StyleSheet styleSheet = kit.getStyleSheet();
>>         styleSheet.addRule("""
>>             body {
>>                 color: #000;
>>                 font-family:times;
>>                 margin: 4px;
>>             }
>>             """);
>>         String htmlString = """
>>             <html>
>>                 <body>
>>                     <input type=image name=point src="file:oracle_logo_50x50.jpg" alt="Logo Oracle JPG">
>>                     <p>
>>                     <input type=image name=point src="file:none_ora...
>
> ScientificWare has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge master
>  - FormView.java :
>    - Pass altAtt as the description parameter in the ImageIcon constructor.
>  - Merge branch 'scientificware-patch-006-HTML-adds_input_tag_image_type_alt_attribute_support' of github.com:scientificware/jdk into scientificware-patch-006-HTML-adds_input_tag_image_type_alt_attribute_support
>  - Update src/java.desktop/share/classes/javax/swing/text/html/FormView.java
>    
>    FormView.java : Remove a redundant space.
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge master
>  - Merge master
>  - Merge master
>  - FormView.java :
>    - Fall back to the src attribute if the alt attribute is missing.
>  - FormView.java : Adds missing space in a while statement. Updates Copyright year.
>  - Merge master
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/71289079...a3e8ce51

Looks good to me.

I wonder if it's possible to write a (unit) test which verifies the new behaviour? and whether it's worth doing.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15319#pullrequestreview-1742114072
PR Comment: https://git.openjdk.org/jdk/pull/15319#issuecomment-1820995877

From aivanov at openjdk.org  Tue Nov 21 14:37:25 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 14:37:25 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v3]
In-Reply-To: <XfLCsSvxaUNuQnKKWfgyVEi5pq0yKSGnROsUdfUDBpw=.90902db2-66f5-46a0-bf88-a996493ce688@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>
 <T8e5aDDEDNSIqlN5Sc5PNUilTc3PvNvJi8wQkJxrckQ=.d679d743-a29f-4df3-890c-9c587ca5d59f@github.com>
 <XfLCsSvxaUNuQnKKWfgyVEi5pq0yKSGnROsUdfUDBpw=.90902db2-66f5-46a0-bf88-a996493ce688@github.com>
Message-ID: <Dfqwa5jm04nVrvElz9oV2hKl8Mh18HutR8e2Nqi1Xvc=.fbbf52ba-10c5-46cf-b2e1-5f8bdbaf1e95@github.com>

On Tue, 21 Nov 2023 08:37:45 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> `boolean` variable is changed to local variable. Others are used in EDT and other method, so kept it as class variables.

Do they need to be? I mean you can do everything on EDT, even throw the exception from there. It could something like this:


public class TestProgressBarBorder {
    public static void main(String[] args) throws Exception {
        for (UIManager.LookAndFeelInfo laf :
                UIManager.getInstalledLookAndFeels()) {
            if (!laf.getName().contains("Nimbus") && !laf.getName().contains("GTK")) {
                continue;
            }
            System.out.println("Testing LAF: " + laf.getName());
            SwingUtilities.invokeAndWait(() -> test(laf));
        }
    }

    private static void test(UIManager.LookAndFeelInfo laf) {
        setLookAndFeel(laf);

        JProgressBar progressBar = createProgressBar();
        progressBar.setBorderPainted(true);
        BufferedImage withBorder = paintToImage(progressBar);
        progressBar.setBorderPainted(false);
        BufferedImage withoutBorder = paintToImage(progressBar);

        boolean equal = Util.compareBufferedImages(withBorder, withoutBorder);
        if (equal) {
            try {
                ImageIO.write(withBorder, "png", new File("withBorder.png"));
                ImageIO.write(withoutBorder, "png", new File("withoutBorder.png"));
            } catch (IOException ignored) {}
            throw new RuntimeException("JProgressBar border is painted when border\n" +
                                       " painting is set to false");
        }
    }

    private static JProgressBar createProgressBar() {
        JProgressBar progressBar = new JProgressBar();
        progressBar.setSize(100, 50);
        progressBar.setValue(0);
        progressBar.setStringPainted(true);
        return progressBar;
    }


Because the exception is thrown from EDT, the exception thrown from main is `InvocationTargetException`, yet the CI will still show you the cause. If you want to avoid it, you can return the boolean value from the `test` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400695948

From aivanov at openjdk.org  Tue Nov 21 15:43:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 15:43:20 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
Message-ID: <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>

On Tue, 21 Nov 2023 12:06:41 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Changes requested by aivanov (Reviewer).

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

> 2029:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMin);
> 2030:         } else {
> 2031:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMax);

The method name `getXPosInRightToLeft` is confusing when you call it for the *left-to-right case*?

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

> 2029:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMin);
> 2030:         } else {
> 2031:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMax);

Does it mean that `table.getCellRect` returns an incorrect value in right-to-left case?

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

> 2086:                 cellRect = table.getCellRect(row, cMin, false);
> 2087:                 for (int column = cMin; column <= cMax; column++) {
> 2088:                     aColumn = cm.getColumn(column);

The bodies of the column loops are absolutely the same now, it asks for refactoring? Yet it could be an overkill.

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

> 2098:             for (int row = rMin; row <= rMax; row++) {
> 2099:                 cellRect = table.getCellRect(row, cMax, false);
> 2100:                 cellRect.x = SwingUtilities2.getXPosInRightToLeft(table, cMax);

Here, I have the same question: _Does it mean that `table.getCellRect` returns an incorrect value in right-to-left case?_

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

> 2106:                         paintCell(g, cellRect, row, column);
> 2107:                     }
> 2108:                     cellRect.x += columnWidth;

This is weird? if we paint columns in right-to-left order, x should decrease.

src/java.desktop/share/classes/sun/swing/SwingUtilities2.java line 2371:

> 2369:             return table.getWidth();
> 2370:         }
> 2371:         return table.getParent().getWidth();

The condition `table != null` seem redundant ? if it's `null`, the expression `table.getParent()` in the return statement throws NPE.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 98:

> 96:                                     table.table.getLocationOnScreen().y,
> 97:                                     table.table.getWidth() - allColumnWidths,
> 98:                                     table.table.getHeight()));

This is the reason why I dislike the model design: `table.table` doesn't look good and is somewhat confusing. Moreover, `CustomTable` is not really _a table_ which makes the design even more confusing: a table contains a table.

I understand over-engineering a test is a waste of time, yet it feels too wrong this way. A clean test code will ease the work of another engineer who will need to deal with updating the test if anything changes.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 161:

> 159:             "Salary",
> 160:     };
> 161:     List<CustomTable.Record> data = new ArrayList();

Suggestion:

    List<CustomTable.Record> data = new ArrayList<>();

The right side still uses raw type.

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 184:

> 182:             this.salary = salary;
> 183:         }
> 184:     }

What I meant is using `record` instead of a *`class`*:

Suggestion:

    record Data(String firstName, String lastName, float salary) {}

test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 204:

> 202:                     return item.lastname;
> 203:                 case COL_SALARY:
> 204:                     return Float.valueOf(item.salary);

Suggestion:

                    return item.salary;

Explicit boxing is redundant.

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

PR Review: https://git.openjdk.org/jdk/pull/16374#pullrequestreview-1742186893
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400701062
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400704002
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400717209
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400704758
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400721169
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400744578
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400782701
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400784213
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400786843
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400788820

From aivanov at openjdk.org  Tue Nov 21 15:43:24 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 15:43:24 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <Vkty-v1al8wl6g6VWjiqeYIKrs041k82EW63fx3Qfmc=.68f15da2-1f2f-4cbf-83e0-658436012938@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
 <Vkty-v1al8wl6g6VWjiqeYIKrs041k82EW63fx3Qfmc=.68f15da2-1f2f-4cbf-83e0-658436012938@github.com>
Message-ID: <_jPsPlrgBukE-ZL0ohohaLHuOZutenPFhG_uMglJMGk=.8280d8e7-0bc8-41c5-8b86-de8475651b1f@github.com>

On Tue, 21 Nov 2023 04:53:35 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 855:
>> 
>>> 853:         }
>>> 854:     }
>>> 855:     private int getXPosition(int column) {
>> 
>> This method is exactly the same as in `BasicTableUI`, if I don't miss anything.
>> 
>> You should rather move this to a utility class which is accessible to both `-UI` classes. Even more: if you're following the same code path that's implemented for `JTableHeader`, you should consider re-using the code from the header painting too? by extracting the relevant parts to a utility class if appropriate.
>> 
>> If another bug is found, it will need to be fixed in *one place* instead of several places which repeat the same code.
>
> The methods can be both moved to Utility class for sure, but not sure of re-using the code from `JTableHeader` coz `getColumnModel()` and `getWidthInRightToLeft()` are specific to it.

How is `getColumnModel()` specific?

I didn't dive into comparing rendering? I expect the gist of it is the same, you mentioned that it was similar. It doesn't necessarily mean the header and table cells can re-use the algorithm, yet I feel it will be beneficial ? one algorithm for the two similar cases, less code duplication.

>> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 57:
>> 
>>> 55:  */
>>> 56: 
>>> 57: public class JTableRightAlignmentTest {
>> 
>> As far as I understood from the description, it's about **Orientation**?left-to-right vs. right-to-left?rather than alignment.
>
> <img width="719" alt="JTableRTLOrientationFix" src="https://github.com/openjdk/jdk/assets/94159358/3de732e6-cab6-4bb0-8c25-724fac22eced">

> As far as I understood from the description, it's about **Orientation**?left-to-right vs. right-to-left?rather than alignment.

My comment referred to `-Alignment` in the test name which should be replaced with `-Orientation` because you're dealing with *orientation* here, not with alignment.

>> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 93:
>> 
>>> 91:                                 .getColumn(2)
>>> 92:                                 .getWidth() - 1;
>>> 93:                 Color expectedRGB = robot.getPixelColor(xPos, yPos);
>> 
>> I suggest capturing the screen rectangle and then sample the colours of the captured buffered image, or alternatively even paint into a buffered image.
>
> Any particular reason for this suggestion ?

It is much more efficient this way: `getPixelColor` captures 1 pixel of the screen but what you really want is to capture the entire table one way or another. Capturing the entire table with `createScreenCapture` once means you read pixels from the screen only once.

Painting to a `BufferedImage` is even more efficient, it avoids accessing screen pixels altogether, and the test could be made headless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400772062
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400749864
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400765296

From aivanov at openjdk.org  Tue Nov 21 15:43:27 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 15:43:27 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <_jPsPlrgBukE-ZL0ohohaLHuOZutenPFhG_uMglJMGk=.8280d8e7-0bc8-41c5-8b86-de8475651b1f@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
 <Vkty-v1al8wl6g6VWjiqeYIKrs041k82EW63fx3Qfmc=.68f15da2-1f2f-4cbf-83e0-658436012938@github.com>
 <_jPsPlrgBukE-ZL0ohohaLHuOZutenPFhG_uMglJMGk=.8280d8e7-0bc8-41c5-8b86-de8475651b1f@github.com>
Message-ID: <SOPll4HvAx10XDuobax1tLrlxiK9vUkPGcKCeu5MPWE=.878e600c-52a9-42c9-8148-405ff3944cbf@github.com>

On Tue, 21 Nov 2023 15:12:14 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> <img width="719" alt="JTableRTLOrientationFix" src="https://github.com/openjdk/jdk/assets/94159358/3de732e6-cab6-4bb0-8c25-724fac22eced">
>
>> As far as I understood from the description, it's about **Orientation**?left-to-right vs. right-to-left?rather than alignment.
> 
> My comment referred to `-Alignment` in the test name which should be replaced with `-Orientation` because you're dealing with *orientation* here, not with alignment.

It looks as if the left border of the leftmost column is missing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400752345

From abhiscxk at openjdk.org  Tue Nov 21 16:50:06 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 16:50:06 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v3]
In-Reply-To: <Dfqwa5jm04nVrvElz9oV2hKl8Mh18HutR8e2Nqi1Xvc=.fbbf52ba-10c5-46cf-b2e1-5f8bdbaf1e95@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>
 <T8e5aDDEDNSIqlN5Sc5PNUilTc3PvNvJi8wQkJxrckQ=.d679d743-a29f-4df3-890c-9c587ca5d59f@github.com>
 <XfLCsSvxaUNuQnKKWfgyVEi5pq0yKSGnROsUdfUDBpw=.90902db2-66f5-46a0-bf88-a996493ce688@github.com>
 <Dfqwa5jm04nVrvElz9oV2hKl8Mh18HutR8e2Nqi1Xvc=.fbbf52ba-10c5-46cf-b2e1-5f8bdbaf1e95@github.com>
Message-ID: <u23CcxQCfaYJZf_bK_-Jud07IC63BXPU3i3QSv14C48=.e02cbb00-dab1-44c0-b8ae-0f780ee64217@github.com>

On Tue, 21 Nov 2023 14:34:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Do they need to be? I mean you can do everything on EDT, even throw the exception from there. 

Yeah, everything can be done on EDT but what is the advantage of that?
I mean as per current test, swing UI components are accessed on EDT and then the comparison is done on main thread. 

Curious to know what we achieve extra by doing the way you suggested above?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400886219

From aivanov at openjdk.org  Tue Nov 21 16:57:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 16:57:10 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
Message-ID: <xMXS9EjymcS-S__xKKEu-jb7n1O0Up8fkvMW_vYecuE=.4953a683-a30a-45bb-b260-48355f94ce59@github.com>

On Tue, 21 Nov 2023 14:40:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Does it mean that `table.getCellRect` returns an incorrect value in right-to-left case?

Yes, it does! Clicking to select doesn't work correctly: wherever I click only the Salary column gets selected, there's no way to move selection to another cell (*visibly* at least), editing doesn't work either: if I select the Salary cell in the first row and press F2 to edit the value, the editor appears in the left top corner where the cell rendered before the fix.

To enable editing, add


        @Override
        public boolean isCellEditable(int rowIndex, int columnIndex) {
            return true;
        }


to the `Model` class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400895980

From aivanov at openjdk.org  Tue Nov 21 17:06:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 17:06:17 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <xMXS9EjymcS-S__xKKEu-jb7n1O0Up8fkvMW_vYecuE=.4953a683-a30a-45bb-b260-48355f94ce59@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
 <xMXS9EjymcS-S__xKKEu-jb7n1O0Up8fkvMW_vYecuE=.4953a683-a30a-45bb-b260-48355f94ce59@github.com>
Message-ID: <JYw5eAk4K5Zsi_rTfj3z1lR8R48KSXPleBYStxRhlns=.d139c807-b242-4ada-976a-52493a6fe340@github.com>

On Tue, 21 Nov 2023 16:54:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2031:
>> 
>>> 2029:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMin);
>>> 2030:         } else {
>>> 2031:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMax);
>> 
>> Does it mean that `table.getCellRect` returns an incorrect value in right-to-left case?
>
>> Does it mean that `table.getCellRect` returns an incorrect value in right-to-left case?
> 
> Yes, it does! Clicking to select doesn't work correctly: wherever I click only the Salary column gets selected, there's no way to move selection to another cell (*visibly* at least), editing doesn't work either: if I select the Salary cell in the first row and press F2 to edit the value, the editor appears in the left top corner where the cell rendered before the fix.
> 
> To enable editing, add
> 
> 
>         @Override
>         public boolean isCellEditable(int rowIndex, int columnIndex) {
>             return true;
>         }
> 
> 
> to the `Model` class.

> there's no way to move selection to another cell (_visibly_ at least)

Yes, the selection moves but you can't see it. Moving the cell to editable state brings up the editor which is positioned like on [your screenshot above](https://github.com/openjdk/jdk/pull/16374#discussion_r1400007130) without the fix.

It looks to me what you should actually change is the implementation of `JTable.getCellRect` so that returns the *correct* coordinates when the orientation is set to right-to-left and rendering will fix automatically.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1400906937

From aivanov at openjdk.org  Tue Nov 21 17:16:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 17:16:09 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v4]
In-Reply-To: <VmdwpwlLawjlKVPcFYL5k4dXJyqbw-vNiD12kU1VtYU=.9c27975c-aaa8-43f6-b269-4fad7b0361d1@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <VmdwpwlLawjlKVPcFYL5k4dXJyqbw-vNiD12kU1VtYU=.9c27975c-aaa8-43f6-b269-4fad7b0361d1@github.com>
Message-ID: <nHkO6qUTT9qECtd6yc4tX9ybssdQFwwG5ubub9Vw-aY=.223737c5-90ad-47c7-a786-d6fb5191a938@github.com>

On Tue, 21 Nov 2023 08:42:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16467#pullrequestreview-1742600416

From aivanov at openjdk.org  Tue Nov 21 17:16:11 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 17:16:11 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v3]
In-Reply-To: <u23CcxQCfaYJZf_bK_-Jud07IC63BXPU3i3QSv14C48=.e02cbb00-dab1-44c0-b8ae-0f780ee64217@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>
 <T8e5aDDEDNSIqlN5Sc5PNUilTc3PvNvJi8wQkJxrckQ=.d679d743-a29f-4df3-890c-9c587ca5d59f@github.com>
 <XfLCsSvxaUNuQnKKWfgyVEi5pq0yKSGnROsUdfUDBpw=.90902db2-66f5-46a0-bf88-a996493ce688@github.com>
 <Dfqwa5jm04nVrvElz9oV2hKl8Mh18HutR8e2Nqi1Xvc=.fbbf52ba-10c5-46cf-b2e1-5f8bdbaf1e95@github.com>
 <u23CcxQCfaYJZf_bK_-Jud07IC63BXPU3i3QSv14C48=.e02cbb00-dab1-44c0-b8ae-0f780ee64217@github.com>
Message-ID: <rAPa0eeki-uTLA87uyLI0j1nYPgJ9rySI4Fofyj0thc=.4b8675a9-c712-46db-801a-62e3190da03f@github.com>

On Tue, 21 Nov 2023 16:47:10 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > Do they need to be? I mean you can do everything on EDT, even throw the exception from there.
> 
> Yeah, everything can be done on EDT but what is the advantage of that?

Less code, all the variables are local in one method, no need to care about any synchronisation whatsoever.

> I mean as per current test, swing UI components are accessed on EDT and then the comparison is done on main thread.
> 
> Curious to know what we achieve extra by doing the way you suggested above?

What do we achieve by separating painting and comparing?

There's no way that's the only right one. Both do the same. Yet a single test-method which does everything is easier to understand: set look-and-feel, get a progress bar, paint it with and without border and, finally, compare the images. I'm always for this style.

When dealing with multiple threads you have to pass objects between threads; to do so, you store them as static fields ? it somewhat complicates the data flow.

However, there's still one advantage to this ? a clearer exception about the failure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400918028

From abhiscxk at openjdk.org  Tue Nov 21 17:34:28 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 17:34:28 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v3]
In-Reply-To: <rAPa0eeki-uTLA87uyLI0j1nYPgJ9rySI4Fofyj0thc=.4b8675a9-c712-46db-801a-62e3190da03f@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <2FhiH4sFooILvvHTHCpk_fE5s0LOK23Ic8TpYvRs1-A=.3591313c-6c31-4219-aa2d-c6acf6f21c4d@github.com>
 <T8e5aDDEDNSIqlN5Sc5PNUilTc3PvNvJi8wQkJxrckQ=.d679d743-a29f-4df3-890c-9c587ca5d59f@github.com>
 <XfLCsSvxaUNuQnKKWfgyVEi5pq0yKSGnROsUdfUDBpw=.90902db2-66f5-46a0-bf88-a996493ce688@github.com>
 <Dfqwa5jm04nVrvElz9oV2hKl8Mh18HutR8e2Nqi1Xvc=.fbbf52ba-10c5-46cf-b2e1-5f8bdbaf1e95@github.com>
 <u23CcxQCfaYJZf_bK_-Jud07IC63BXPU3i3QSv14C48=.e02cbb00-dab1-44c0-b8ae-0f780ee64217@github.com>
 <rAPa0eeki-uTLA87uyLI0j1nYPgJ9rySI4Fofyj0thc=.4b8675a9-c712-46db-801a-62e3190da03f@github.com>
Message-ID: <NAk_wDMmfYpFQ21LfZs1JEGmwLGNCNyWsj8sZmys7u4=.c29e3574-14b7-49e9-ab8a-4fbada335e30@github.com>

On Tue, 21 Nov 2023 17:12:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Do they need to be? I mean you can do everything on EDT, even throw the exception from there. 
>> 
>> Yeah, everything can be done on EDT but what is the advantage of that?
>> I mean as per current test, swing UI components are accessed on EDT and then the comparison is done on main thread. 
>> 
>> Curious to know what we achieve extra by doing the way you suggested above?
>
>> > Do they need to be? I mean you can do everything on EDT, even throw the exception from there.
>> 
>> Yeah, everything can be done on EDT but what is the advantage of that?
> 
> Less code, all the variables are local in one method, no need to care about any synchronisation whatsoever.
> 
>> I mean as per current test, swing UI components are accessed on EDT and then the comparison is done on main thread.
>> 
>> Curious to know what we achieve extra by doing the way you suggested above?
> 
> What do we achieve by separating painting and comparing?
> 
> There's no way that's the only right one. Both do the same. Yet a single test-method which does everything is easier to understand: set look-and-feel, get a progress bar, paint it with and without border and, finally, compare the images. I'm always for this style.
> 
> When dealing with multiple threads you have to pass objects between threads; to do so, you store them as static fields ? it somewhat complicates the data flow.
> 
> However, there's still one advantage to this ? a clearer exception about the failure.

Sounds good.
Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400938186

From aivanov at openjdk.org  Tue Nov 21 17:34:30 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 17:34:30 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v4]
In-Reply-To: <VmdwpwlLawjlKVPcFYL5k4dXJyqbw-vNiD12kU1VtYU=.9c27975c-aaa8-43f6-b269-4fad7b0361d1@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <VmdwpwlLawjlKVPcFYL5k4dXJyqbw-vNiD12kU1VtYU=.9c27975c-aaa8-43f6-b269-4fad7b0361d1@github.com>
Message-ID: <SZJrMPDsXELra-d0MvGTZLiPM3cMXAhzCV6He7H6oDY=.5ac61903-11aa-412c-abf7-b4cd9150ae73@github.com>

On Tue, 21 Nov 2023 08:42:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 73:

> 71:                 ImageIO.write(withoutBorder, "png", new File("withoutBorder.png"));
> 72:                 throw new RuntimeException("JProgressBar border is painted when border\n" +
> 73:                         " painting is set to false");

Suggestion:

                throw new RuntimeException("JProgressBar border is painted when border " +
                        "painting is set to false");

You should probably remove the line break from the error message.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1400919095

From abhiscxk at openjdk.org  Tue Nov 21 17:34:26 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 17:34:26 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v5]
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <9t63nY_BvywwMYocZFHvrhu6CofIKkOGYC2cAQMcG84=.0f74fb42-f5f6-4565-a30f-c0a095770aa3@github.com>

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16467/files
  - new: https://git.openjdk.org/jdk/pull/16467/files/ee48ccda..93c88c90

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

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

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

From prr at openjdk.org  Tue Nov 21 17:49:37 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Nov 2023 17:49:37 GMT
Subject: Integrated: 8318364: Add an FFM-based implementation of harfbuzz
 OpenType layout
In-Reply-To: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
References: <PZkn_pbtAQMEllHoCjR1L94fmHfe5YGjMPpILBom5x0=.5572e895-1a63-4e8a-9b87-9647bb793281@github.com>
Message-ID: <os2VzaqgWEGTbE0GpvW8dlYTV3Qgr6neA1bmpal370g=.fa567d33-95d3-4b7f-b9d5-60d4461d706b@github.com>

On Tue, 29 Aug 2023 22:04:40 GMT, Phil Race <prr at openjdk.org> wrote:

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

This pull request has now been integrated.

Changeset: f69e6653
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f69e6653f86a7dd781db6c8523f114c0d3f7ccbc
Stats:     1376 lines in 7 files changed: 1373 ins; 0 del; 3 mod

8318364: Add an FFM-based implementation of harfbuzz OpenType layout

Reviewed-by: jdv, psadhukhan

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

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

From abhiscxk at openjdk.org  Tue Nov 21 17:59:02 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 17:59:02 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v6]
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

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

  Remove line break

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16467/files
  - new: https://git.openjdk.org/jdk/pull/16467/files/93c88c90..a00f11fe

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

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

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

From abhiscxk at openjdk.org  Tue Nov 21 17:59:08 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 17:59:08 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v2]
In-Reply-To: <o-bxcNcM3q3Vq4TjcqP_6HE52QUAM3dWqLqkgC18DY4=.50aebe20-b728-4f9d-b52f-55a54469d6bf@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <dp2SajUlqqSR5yMsvPCi_Bf6LZZBcBPPMz2ta1Dx4jY=.f1ac9324-11e9-48bd-ac69-a0fb276b6865@github.com>
 <o-bxcNcM3q3Vq4TjcqP_6HE52QUAM3dWqLqkgC18DY4=.50aebe20-b728-4f9d-b52f-55a54469d6bf@github.com>
Message-ID: <Pv_ZAfaCd3wzvyL1wCN6eP7ZDdpGnYD21-E3iE2k7QM=.0a9721a4-ca6f-4692-8a53-4ef9c6866baa@github.com>

On Fri, 17 Nov 2023 23:05:45 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> Changes look logical and work as expected.

@DamonGuy Can you please re-review the latest changes?

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

PR Comment: https://git.openjdk.org/jdk/pull/16467#issuecomment-1821394947

From dnguyen at openjdk.org  Tue Nov 21 18:04:10 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 21 Nov 2023 18:04:10 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v6]
In-Reply-To: <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>
Message-ID: <UvrpBYd3xQ52xVGMdz9TX4QBf5pmHfEHG_vlScRtNPE=.0cfd7c5b-855b-4cdb-8d2d-2298d3989b28@github.com>

On Tue, 21 Nov 2023 17:59:02 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove line break

The additional changes look good to me. Cleaner and more readable

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16467#pullrequestreview-1742741760

From nikita.provotorov at jetbrains.com  Tue Nov 21 18:07:33 2023
From: nikita.provotorov at jetbrains.com (Nikita Provotorov)
Date: Tue, 21 Nov 2023 19:07:33 +0100
Subject: Is it valid to call JComponent#paintImmediately on a non-EDT
 thread (yet)?
In-Reply-To: <796fa293-0824-444b-ae32-fe58edf3cc4b@oracle.com>
References: <CAMTdVeoVr=xzqsMHXeLdZR09G+O8U_AtwTTGS6xPj2PXTheWJw@mail.gmail.com>
 <895ab355-9586-4c49-8384-a660ae8483ae@oracle.com>
 <CAMTdVerbDWuq9s6yzcJYnChbefZGBSj-zJ2mxt7LbgCisK52_A@mail.gmail.com>
 <796fa293-0824-444b-ae32-fe58edf3cc4b@oracle.com>
Message-ID: <CAMTdVeoW=C+Zy+RtrwW3OpkCzkbf3pF39u+v7wN-X=BaFY4Nbg@mail.gmail.com>

Could you please elaborate why the implementation of
sun.awt.X11.XTextAreaPeer#repaintText
<https://github.com/openjdk/jdk/blob/8ec6b8de3bb3d7aeebdcb45d761b18cce3bab75e/src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java#L258>
is
*correct*?

Also let me add more context to the question:
With one of the X11 regression tests on our infrastructure, we're
struggling with a deadlock when the test invokes the public AWT's API
method *java.awt.TextComponent#setText* *outside of EDT* while EDT is
dispatching an input event. Sometimes, it leads to the situation when EDT
obtains the AWT tree lock and is trying to lock the instance of
*java.awt.TextComponent* while the call of
*java.awt.TextComponent#setText* (which
is on a different thread), in opposite, locks self and is trying to obtain
the AWT tree lock. Here is a classical deadlock.

Before this discussion, I was strongly convinced that AWT guarantees
thread-safety in the sense that it's safe to invoke any of its (not
Swing's) public UI operations on any thread. However I can't find any proof
(or refutation) about this in the AWT documentation now. Is it wrong?

If there's such a guarantee, let's take a look at the case described above
again:
* The test seems correctly written, although it invokes
*java.awt.TextComponent#setText* outside of EDT.
* But it internally leads to a call of sun.awt.X11.XTextAreaPeer#repaintText
<https://github.com/openjdk/jdk/blob/8ec6b8de3bb3d7aeebdcb45d761b18cce3bab75e/src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java#L258>
which,
in this case, calls Swing API outside of EDT, which is definitely
incorrect. Thus we must fix the implementation
of XTextAreaPeer#repaintText, not the test, right?

*Summarizing all the questions:*
* Does AWT (still) guarantee thread-safety? The question is about AWT only,
excluding Swing.
* If it does, the implementation of sun.awt.X11.XTextAreaPeer#repaintText
<https://github.com/openjdk/jdk/blob/8ec6b8de3bb3d7aeebdcb45d761b18cce3bab75e/src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java#L258>
doesn't
take this into account, so it must be fixed, mustn't it?

Thanks in advance!

Best regards,
Nikita Provotorov


On Fri, Nov 17, 2023 at 7:42?PM Philip Race <philip.race at oracle.com> wrote:

> No, the code that calls setText() is where it starts.
>
> -phil.
>
> On 11/17/23 2:51 AM, Nikita Provotorov wrote:
>
> Thanks for the response!
> However I'd like to clarify: is it correct to say that the current
> implementation of sun.awt.X11.XTextAreaPeer#repaintText
> <https://github.com/openjdk/jdk/blob/8ec6b8de3bb3d7aeebdcb45d761b18cce3bab75e/src/java.desktop/unix/classes/sun/awt/X11/XTextAreaPeer.java#L258> is
> wrong because it doesn't make sure if
> *javax.swing.JComponent#paintImmediately* is called on EDT only (e.g. via
> *SwingUtilities#invokeLater*)?
>
> Best regards,
> Nikita Provotorov
>
>
> On Thu, Nov 16, 2023 at 9:30?PM Philip Race <philip.race at oracle.com>
> wrote:
>
>> Because (like in this case), an AWT component might actually be
>> implemented using Swing,
>> the recommendation is to treat AWT components like Swing, and update them
>> only on the EDT.
>>
>> -phil.
>>
>> On 11/15/23 4:01 PM, Nikita Provotorov wrote:
>>
>> Hello!
>> I've discovered that on X11 platforms a call
>> of java.awt.TextComponent#setText can lead to a call
>> of javax.swing.JComponent#paintImmediately(java.awt.Rectangle) on the same
>> thread.
>> Since java.awt.TextComponent#setText is allowed to be called on any
>> thread (because it's AWT, not Swing), JComponent#paintImmediately may be
>> called outside of EDT. Is this a valid behavior?
>>
>> The following stacktrace shows how exactly this can happen:
>>
>>> at javax.swing.JComponent.paintImmediately
>>> at sun.awt.X11.XTextAreaPeer$AWTTextArea.repaintNow
>>> at sun.awt.X11.XTextAreaPeer.repaintText
>>> at sun.awt.X11.XTextAreaPeer.setText
>>> at java.awt.TextComponent.setText
>>
>>
>> Best regards,
>> Nikita Provotorov
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231121/1262d40c/attachment-0001.htm>

From abhiscxk at openjdk.org  Tue Nov 21 18:15:22 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 18:15:22 GMT
Subject: RFR: 8225220: When the Tab Policy is checked,the scroll button
 direction displayed incorrectly.
Message-ID: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>

JTabbedPane scroll button direction was incorrect because the widget type returned while painting the arrow was `SPINNER_ARROW_BUTTON`. Added the condition check for JTabbedPane before returning the widget type and based on the tab placement set by user, appropriate widget type is returned.

Tested the CI jobs against the fix and it was green. Link attached in JBS.

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

Commit messages:
 - Remove frame dispose
 - JTabbedPane arrow direction fix

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

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

From tr at openjdk.org  Tue Nov 21 18:15:23 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 21 Nov 2023 18:15:23 GMT
Subject: RFR: 8225220: When the Tab Policy is checked,the scroll button
 direction displayed incorrectly.
In-Reply-To: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
References: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
Message-ID: <hX72sN2BuVq_275MEnClwXIw80YrRfR3BB1-dlFc-r4=.b847d7fe-38ff-48b1-a5c3-f212cbbd1889@github.com>

On Fri, 10 Nov 2023 11:20:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JTabbedPane scroll button direction was incorrect because the widget type returned while painting the arrow was `SPINNER_ARROW_BUTTON`. Added the condition check for JTabbedPane before returning the widget type and based on the tab placement set by user, appropriate widget type is returned.
> 
> Tested the CI jobs against the fix and it was green. Link attached in JBS.

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneArrowDirection.java line 75:

> 73:             SwingUtilities.invokeAndWait(() -> {
> 74:                 if (frame != null) {
> 75:                     frame.dispose();

Dispose is not required here, since you are adding it to passFailJFrame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16601#discussion_r1391966574

From abhiscxk at openjdk.org  Tue Nov 21 18:15:24 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 21 Nov 2023 18:15:24 GMT
Subject: RFR: 8225220: When the Tab Policy is checked,the scroll button
 direction displayed incorrectly.
In-Reply-To: <hX72sN2BuVq_275MEnClwXIw80YrRfR3BB1-dlFc-r4=.b847d7fe-38ff-48b1-a5c3-f212cbbd1889@github.com>
References: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
 <hX72sN2BuVq_275MEnClwXIw80YrRfR3BB1-dlFc-r4=.b847d7fe-38ff-48b1-a5c3-f212cbbd1889@github.com>
Message-ID: <yE_g_LRe1_vfNKc_-maMjjxap2_6RjpeZWPCj-HDyCc=.44d3bf9b-1807-4e5d-a0ba-79c27cc76f5e@github.com>

On Tue, 14 Nov 2023 04:22:57 GMT, Tejesh R <tr at openjdk.org> wrote:

>> JTabbedPane scroll button direction was incorrect because the widget type returned while painting the arrow was `SPINNER_ARROW_BUTTON`. Added the condition check for JTabbedPane before returning the widget type and based on the tab placement set by user, appropriate widget type is returned.
>> 
>> Tested the CI jobs against the fix and it was green. Link attached in JBS.
>
> test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneArrowDirection.java line 75:
> 
>> 73:             SwingUtilities.invokeAndWait(() -> {
>> 74:                 if (frame != null) {
>> 75:                     frame.dispose();
> 
> Dispose is not required here, since you are adding it to passFailJFrame.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16601#discussion_r1392012330

From duke at openjdk.org  Tue Nov 21 19:30:18 2023
From: duke at openjdk.org (Alec Su)
Date: Tue, 21 Nov 2023 19:30:18 GMT
Subject: Integrated: 8074211: javax.sound.midi: Error with send System
 Exclusive messages of different length
In-Reply-To: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
Message-ID: <8cfN2tZ-9kvuE9JfaepDaxJowPkIDqMF1q-x5bG_nQk=.3ac1c337-ace7-4853-b229-3b4a9fffe352@github.com>

On Fri, 27 Oct 2023 11:10:45 GMT, Alec Su <duke at openjdk.org> wrote:

> JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.
> 
> The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.
> 
> 
> import javax.sound.midi.*;
> 
> public class MidiTest {
>     public static class RawMidiMessage extends MidiMessage {
>         public RawMidiMessage(byte[] data) {
>             super(data);
>         }
> 
>         @Override
>         public Object clone() {
>             return new RawMidiMessage(this.getMessage());
>         }
>     }
> 
>     public static void main(String[] args) {
>         var deviceInfos = MidiSystem.getMidiDeviceInfo();
>         for (var info : deviceInfos) {
>             try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
>                 if (device.getMaxReceivers() != 0) {
>                     System.out.println("Open MIDI port: " + info.getName());
>                     device.open();
>                     Receiver receiver = device.getReceiver();
>                     // Send two sysex messages at once
>                     receiver.send(new RawMidiMessage(new byte[]{
>                             (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
>                             (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
>                         }), -1);
>                     // Send another sysex message
>                     receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
>                 }
>             } catch (MidiUnavailableException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> }
> 
> 
> The expected messages received should be the following three messages
> 
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
> 
> 
> But acually four messages was received with the second message repeated twice.
> 
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
> F0 7D 02 F7
> 
> 
> To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buffer hasn't been freed due to an error.
> 
> It seems that the patch may also resolve JDK-8250667. The extra bytes in the s...

This pull request has now been integrated.

Changeset: e47cf611
Author:    Alec Su <ae40515 at yahoo.com.tw>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e47cf611c9490225e50a548787cbba66ab147058
Stats:     46 lines in 5 files changed: 20 ins; 0 del; 26 mod

8074211: javax.sound.midi: Error with send System Exclusive messages of different length
8250667: MIDI sysex over USB scrambled when reply length matches previous message

Reviewed-by: prr

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

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

From aivanov at openjdk.org  Tue Nov 21 20:04:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 21 Nov 2023 20:04:14 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v6]
In-Reply-To: <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>
Message-ID: <Lba6k_CS1BGLHLFLsRk4GFdnu0tjuM1cra5ivKZlDgg=.a7cfbfaf-e323-4383-acda-1dfc1dbcf9d8@github.com>

On Tue, 21 Nov 2023 17:59:02 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove line break

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 28:

> 26: import java.lang.reflect.InvocationTargetException;
> 27: import java.awt.Graphics;
> 28: import java.awt.image.BufferedImage;

IDEA at my end disagrees with the current sorting order:
Suggestion:

import java.awt.Graphics;
import java.awt.image.BufferedImage;
import java.io.File;
import java.io.IOException;

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 51:

> 49: public class TestProgressBarBorder {
> 50:     public static void main(String[] args) throws InvocationTargetException,
> 51:             InterruptedException {

Suggestion:

    public static void main(String[] args) throws Exception {

In a test we usually don't care about checked exception, therefore `throws Exception` is perfectly fine ? it's what you usually see instead of the pair of `InvocationTargetException` and `InterruptedException` thrown by `invokeAndWait`.

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 75:

> 73:                 ImageIO.write(withBorder, "png", new File("withBorder.png"));
> 74:                 ImageIO.write(withoutBorder, "png", new File("withoutBorder.png"));
> 75:             } catch (IOException e) {}

Suggestion:

            } catch (IOException ignored) {}

Naming the exception parameter `ignored` lets IDE know the exception is ignored, which removes the warning about *ignoring the exception*.

(I used the name `ignored` in the snippet I pasted specifically for this reason.)

test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 76:

> 74:                 ImageIO.write(withoutBorder, "png", new File("withoutBorder.png"));
> 75:             } catch (IOException e) {}
> 76:             throw new RuntimeException("JProgressBar border is painted when border " +

Let's add a blank line before the `throw` statement, it'll stand out better from the preceding code.

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

PR Review: https://git.openjdk.org/jdk/pull/16467#pullrequestreview-1742925323
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1401072905
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1401075040
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1401076413
PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1401078292

From prr at openjdk.org  Tue Nov 21 21:29:19 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Nov 2023 21:29:19 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS
Message-ID: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>

For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
a printer would give you null for the defaultTransform.
Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
We have a test that would have caught it except that until recently the macOS printing implementation
was swallowing exceptions it should not.

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

Commit messages:
 - 8320443

Changes: https://git.openjdk.org/jdk/pull/16773/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16773&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320443
  Stats: 74 lines in 4 files changed: 36 ins; 8 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/16773.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16773/head:pull/16773

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

From prr at openjdk.org  Tue Nov 21 21:29:21 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 21 Nov 2023 21:29:21 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS
In-Reply-To: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
Message-ID: <T-6KbCO9HUl0oIgU0qsVwtkPNffl8YepCqe9IV-bbYs=.3a3af10f-21da-4a22-917c-1a79a6d48f9b@github.com>

On Tue, 21 Nov 2023 21:23:12 GMT, Phil Race <prr at openjdk.org> wrote:

> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
> a printer would give you null for the defaultTransform.
> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
> We have a test that would have caught it except that until recently the macOS printing implementation
> was swallowing exceptions it should not.

src/java.desktop/share/classes/sun/print/PSPrinterJob.java line 266:

> 264:    private AffineTransform mLastTransform;
> 265: 
> 266:    private double xres = PS_XRES;

This change has absolutely nothing to with the bug, but I just happened to notice it as I was bumbling around the various sources.
Its a pure clean up since both are "300", and it just seemed to me it wasn't worth the overhead of a bug of its own so I include it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1401217473

From abhiscxk at openjdk.org  Wed Nov 22 03:30:08 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Nov 2023 03:30:08 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v6]
In-Reply-To: <Lba6k_CS1BGLHLFLsRk4GFdnu0tjuM1cra5ivKZlDgg=.a7cfbfaf-e323-4383-acda-1dfc1dbcf9d8@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>
 <Lba6k_CS1BGLHLFLsRk4GFdnu0tjuM1cra5ivKZlDgg=.a7cfbfaf-e323-4383-acda-1dfc1dbcf9d8@github.com>
Message-ID: <BmP07Ynj26JHjCpvbuo4-Hmm9ATBOtK3xHcIQntm-Ik=.0ea1c8b1-4b99-4519-a68f-42bab94ab1e1@github.com>

On Tue, 21 Nov 2023 19:30:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove line break
>
> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 28:
> 
>> 26: import java.lang.reflect.InvocationTargetException;
>> 27: import java.awt.Graphics;
>> 28: import java.awt.image.BufferedImage;
> 
> IDEA at my end disagrees with the current sorting order:
> Suggestion:
> 
> import java.awt.Graphics;
> import java.awt.image.BufferedImage;
> import java.io.File;
> import java.io.IOException;

I know that the sorting order is not correct but I received a comment on my other PR https://github.com/openjdk/jdk/pull/16674#discussion_r1394632505 which suggests `it is long standing convention that the "core"
packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones.` That's the reason I didn't sorted the imports.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1401458695

From abhiscxk at openjdk.org  Wed Nov 22 04:25:38 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Nov 2023 04:25:38 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v7]
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <8Sictv3wzhD4_Td2c3wSjeqR-E9muKUk_GLJCRCjgIA=.0a4da67b-45c6-4123-a1b7-ba1cab35cb10@github.com>

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

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

  Minor fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16467/files
  - new: https://git.openjdk.org/jdk/pull/16467/files/a00f11fe..a7a45526

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

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

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

From abhiscxk at openjdk.org  Wed Nov 22 04:25:39 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Nov 2023 04:25:39 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v6]
In-Reply-To: <Lba6k_CS1BGLHLFLsRk4GFdnu0tjuM1cra5ivKZlDgg=.a7cfbfaf-e323-4383-acda-1dfc1dbcf9d8@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>
 <Lba6k_CS1BGLHLFLsRk4GFdnu0tjuM1cra5ivKZlDgg=.a7cfbfaf-e323-4383-acda-1dfc1dbcf9d8@github.com>
Message-ID: <qcuIY9G60tuTSmU4DQ966ksWHxUsR0375cE4Ic4WdCA=.ceed6fbf-3ca8-4702-9200-6d85e1cad25e@github.com>

On Tue, 21 Nov 2023 19:34:19 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove line break
>
> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 75:
> 
>> 73:                 ImageIO.write(withBorder, "png", new File("withBorder.png"));
>> 74:                 ImageIO.write(withoutBorder, "png", new File("withoutBorder.png"));
>> 75:             } catch (IOException e) {}
> 
> Suggestion:
> 
>             } catch (IOException ignored) {}
> 
> Naming the exception parameter `ignored` lets IDE know the exception is ignored, which removes the warning about *ignoring the exception*.
> 
> (I used the name `ignored` in the snippet I pasted specifically for this reason.)

I missed somehow in previous commit. Updated now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1401486396

From abhiscxk at openjdk.org  Wed Nov 22 05:42:24 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Nov 2023 05:42:24 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <nqQD3M37Dy9USTsdaWr4FhRTWK6J0VJE3KGlyWJj96E=.227906bd-a39a-4a36-9dc1-1ca0dd767a32@github.com>

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

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

  Test update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16674/files
  - new: https://git.openjdk.org/jdk/pull/16674/files/f0f4c969..9c74599c

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

  Stats: 75 lines in 1 file changed: 37 ins; 33 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16674.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16674/head:pull/16674

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

From abhiscxk at openjdk.org  Wed Nov 22 05:42:27 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 22 Nov 2023 05:42:27 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
 <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>
Message-ID: <CiZAb19G2TLwLKALb3mNvDICaS1usoGm9IfaI-BSI6o=.34ae7371-ee3b-4507-b187-73b84d796018@github.com>

On Mon, 20 Nov 2023 19:51:05 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 66:
> 
>> 64:         try {
>> 65:             // create test directory
>> 66:             String tmpDir = System.getProperty("java.io.tmpdir");
> 
> This is the purpose of the [*scratch* directory in jtreg](https://openjdk.org/jtreg/faq.html#scratch-directory), and it's automatically [cleaned up after the test](https://openjdk.org/jtreg/writetests.html#cleanFiles): <q cite="https://openjdk.org/jtreg/writetests.html#cleanFiles">jtreg will automatically clean up any files written in the scratch directory.</q>
> 
> The test is designed for jtreg, so the simplest solution is *to use the current directory*.
> 
> If someone runs the test directly, without using jtreg, then it's their task to set up the current directory or clean up after the test.

For some reasons when I used the `current directory i.e. scratch`, test failed in my local machine.
 `String tmpDir = System.getProperty(".");`

> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 88:
> 
>> 86:                 testFile.mkdir();
>> 87:             }
>> 88:             testFile.deleteOnExit();
> 
> This is confusing: `testFile` is actually a directory.
> 
> You could improve the readability of the test by using methods: `createFoldersOnlyDir`, `createFilesOnlyDir`, `populateDirs`, `populateFiles` or something similar ? it would make the comments in the code unnecessary.

Test updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1401527591
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1401526335

From tr at openjdk.org  Wed Nov 22 06:45:09 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 06:45:09 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
Message-ID: <MWKb1ujvllmtm_CLi5XD35NkBnB5hjff246dkzzcaXQ=.7b5f89f1-2186-42d9-bdb4-1db1c111e406@github.com>

On Tue, 21 Nov 2023 14:38:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2031:
> 
>> 2029:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMin);
>> 2030:         } else {
>> 2031:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMax);
> 
> The method name `getXPosInRightToLeft` is confusing when you call it for the *left-to-right case*?

Yeah, any suggestions?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401577410

From tr at openjdk.org  Wed Nov 22 06:45:11 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 06:45:11 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v5]
In-Reply-To: <SOPll4HvAx10XDuobax1tLrlxiK9vUkPGcKCeu5MPWE=.878e600c-52a9-42c9-8148-405ff3944cbf@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iWe6bL84Y48JzCw4iJeccLJeVQjXqDRiHKooSCgRMLE=.0666e76f-30be-40b3-a8db-2e7820374204@github.com>
 <6KrQDWlptFTO9R_Hn7KngoLHj-cMvkNnyP1v8Uss_H0=.d34c623e-1a67-4aab-af2a-5d042e91e3a5@github.com>
 <Vkty-v1al8wl6g6VWjiqeYIKrs041k82EW63fx3Qfmc=.68f15da2-1f2f-4cbf-83e0-658436012938@github.com>
 <_jPsPlrgBukE-ZL0ohohaLHuOZutenPFhG_uMglJMGk=.8280d8e7-0bc8-41c5-8b86-de8475651b1f@github.com>
 <SOPll4HvAx10XDuobax1tLrlxiK9vUkPGcKCeu5MPWE=.878e600c-52a9-42c9-8148-405ff3944cbf@github.com>
Message-ID: <W46bKlcAghubGM0eHTCkEHOc-ajEvByZmpraJ8oBA_M=.45cd9a51-a27d-4d03-9468-5eb416e7cea1@github.com>

On Tue, 21 Nov 2023 15:13:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> As far as I understood from the description, it's about **Orientation**?left-to-right vs. right-to-left?rather than alignment.
>> 
>> My comment referred to `-Alignment` in the test name which should be replaced with `-Orientation` because you're dealing with *orientation* here, not with alignment.
>
> It looks as if the left border of the leftmost column is missing.

Yeah, but that's not related to this bug/fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401575981

From tr at openjdk.org  Wed Nov 22 07:00:10 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 07:00:10 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
Message-ID: <x-KtVqzZ4GoeYPrj7bVPii5TX6djpSren8TEsIkBt1k=.320c6ce4-7fbf-4ced-8d9d-48cd02073c09@github.com>

On Tue, 21 Nov 2023 14:41:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2100:
> 
>> 2098:             for (int row = rMin; row <= rMax; row++) {
>> 2099:                 cellRect = table.getCellRect(row, cMax, false);
>> 2100:                 cellRect.x = SwingUtilities2.getXPosInRightToLeft(table, cMax);
> 
> Here, I have the same question: _Does it mean that `table.getCellRect` returns an incorrect value in right-to-left case?_

Yes, meaning it doesn't consider the offset to which table has to moved towards right in _right-to-left case_, especially when `Panel `size is more than the fixed `table ` size.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401588886

From tr at openjdk.org  Wed Nov 22 07:07:11 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 07:07:11 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
Message-ID: <DDzRuWuC2JPlDfTe4K9DDp6u4UuGnurY9rHh6dnCsf4=.c1c9857a-a8e2-4ca0-9ae7-b779918fa117@github.com>

On Tue, 21 Nov 2023 14:52:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2108:
> 
>> 2106:                         paintCell(g, cellRect, row, column);
>> 2107:                     }
>> 2108:                     cellRect.x += columnWidth;
> 
> This is weird? if we paint columns in right-to-left order, x should decrease.

Here, we are painting from left-to-right order by starting with last column. It is only a convention, I guess painting this way is more simple that to actually paint from `right-to-left`. Here for both the orientations, we are painting from left-to-right, only difference is how we pick the columns.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401593563

From tr at openjdk.org  Wed Nov 22 07:26:12 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 07:26:12 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
Message-ID: <9P0qcdjzc38JTZN7KeKGpR4jIUGhnBN1GtOWuozOifU=.78d69399-cda1-4abd-904d-bd17bb025026@github.com>

On Tue, 21 Nov 2023 15:33:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> test/jdk/javax/swing/JTable/JTableRightAlignmentTest.java line 98:
> 
>> 96:                                     table.table.getLocationOnScreen().y,
>> 97:                                     table.table.getWidth() - allColumnWidths,
>> 98:                                     table.table.getHeight()));
> 
> This is the reason why I dislike the model design: `table.table` doesn't look good and is somewhat confusing. Moreover, `CustomTable` is not really _a table_ which makes the design even more confusing: a table contains a table.
> 
> I understand over-engineering a test is a waste of time, yet it feels too wrong this way. A clean test code will ease the work of another engineer who will need to deal with updating the test if anything changes.

Will work on it then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401608795

From aturbanov at openjdk.org  Wed Nov 22 07:52:08 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 22 Nov 2023 07:52:08 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS
In-Reply-To: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
Message-ID: <WFTpNdKA-h42jAaQN9GtIfqBYZZrn7HX2EVrDldCnF0=.fd72f92e-63e0-4bec-a450-482a1730ce3c@github.com>

On Tue, 21 Nov 2023 21:23:12 GMT, Phil Race <prr at openjdk.org> wrote:

> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
> a printer would give you null for the defaultTransform.
> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
> We have a test that would have caught it except that until recently the macOS printing implementation
> was swallowing exceptions it should not.

src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2096:

> 2094: 
> 2095:     synchronized protected void setGraphicsConfigInfo(AffineTransform at,
> 2096:                                             double pw, double ph) {

Let's use blessed modifiers order
Suggestion:

    protected synchronized void setGraphicsConfigInfo(AffineTransform at,
                                                      double pw, double ph) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1401632131

From alexsch at openjdk.org  Wed Nov 22 07:55:09 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Wed, 22 Nov 2023 07:55:09 GMT
Subject: RFR: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <Qg8NPWUzyer14_Lju4zcNkSng4DZKtA0h_yqxp7Tk3A=.87d9b8b4-2fef-4e25-bf70-bf19bdd79b87@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
 <Qg8NPWUzyer14_Lju4zcNkSng4DZKtA0h_yqxp7Tk3A=.87d9b8b4-2fef-4e25-bf70-bf19bdd79b87@github.com>
Message-ID: <ayytX-d6UUNGWDPECKLKN87CNzWRUydyp8w2Uyv74Lg=.a1791b76-cb2a-4a6d-94b2-0b65e62b7813@github.com>

On Mon, 20 Nov 2023 10:04:42 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
>> The same is true for `CustomMediaTray` class.
>> 
>> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
>> 
>> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.
>
> test/jdk/javax/print/CustomMediaSizeNameOOMETest.java line 37:
> 
>> 35: 
>> 36: public class CustomMediaSizeNameOOMETest {
>> 37: 
> 
> Seems testcase is passing for me even without the fix in windows

Yes, this is true. I am not able to reproduce the issue on Windows. It seems that it can be specific to Linux and macOS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16167#discussion_r1401635690

From psadhukhan at openjdk.org  Wed Nov 22 09:02:14 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 22 Nov 2023 09:02:14 GMT
Subject: RFR: 8320057: [macos14] javax/swing/JToolTip/4846413/bug4846413.java:
 Tooltip has not been found!
Message-ID: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>

Test failing on macos14 citing "ToolTip not found"...Investigation shows that the mouse is not moved when invoked 1st time to desired location on screen causing tooltip to not show...However, subsequent runs of the same test without any change causes it to pass every time.
Workaround is proposed to check if running on 14.x, then invoke a dummy mouse movement to same location which causes the test to pass for several iterations in macos14 environment.

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

Commit messages:
 - 8320057: [macos14] javax/swing/JToolTip/4846413/bug4846413.java: Tooltip has not been found!
 - 8320057: [macos14] javax/swing/JToolTip/4846413/bug4846413.java: Tooltip has not been found!

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

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

From tr at openjdk.org  Wed Nov 22 09:23:14 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 09:23:14 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <JYw5eAk4K5Zsi_rTfj3z1lR8R48KSXPleBYStxRhlns=.d139c807-b242-4ada-976a-52493a6fe340@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
 <xMXS9EjymcS-S__xKKEu-jb7n1O0Up8fkvMW_vYecuE=.4953a683-a30a-45bb-b260-48355f94ce59@github.com>
 <JYw5eAk4K5Zsi_rTfj3z1lR8R48KSXPleBYStxRhlns=.d139c807-b242-4ada-976a-52493a6fe340@github.com>
Message-ID: <D-MiJHG5qQvAQyWUXm4Rw_m0hTTTo8pGQ5HJB4H5y8U=.433cc2b2-f9ff-4114-b09a-d5d3c2228db0@github.com>

On Tue, 21 Nov 2023 17:02:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Does it mean that `table.getCellRect` returns an incorrect value in right-to-left case?
>> 
>> Yes, it does! Clicking to select doesn't work correctly: wherever I click only the Salary column gets selected, there's no way to move selection to another cell (*visibly* at least), editing doesn't work either: if I select the Salary cell in the first row and press F2 to edit the value, the editor appears in the left top corner where the cell rendered before the fix.
>> 
>> To enable editing, add
>> 
>> 
>>         @Override
>>         public boolean isCellEditable(int rowIndex, int columnIndex) {
>>             return true;
>>         }
>> 
>> 
>> to the `Model` class.
>
>> there's no way to move selection to another cell (_visibly_ at least)
> 
> Yes, the selection moves but you can't see it. Moving the cell to editable state brings up the editor which is positioned like on [your screenshot above](https://github.com/openjdk/jdk/pull/16374#discussion_r1400007130) without the fix.
> 
> It looks to me what you should actually change is the implementation of `JTable.getCellRect` so that returns the *correct* coordinates when the orientation is set to right-to-left and rendering will fix automatically.

Yeah, actually  `JTable.getCellRect` can be changed/updated to handle this. Will work on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401738490

From tr at openjdk.org  Wed Nov 22 09:51:08 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 09:51:08 GMT
Subject: RFR: 8225220: When the Tab Policy is checked,the scroll button
 direction displayed incorrectly.
In-Reply-To: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
References: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
Message-ID: <n-0FVbVmU6BCrDGOruHB9WudazFwvrEhXSdAA9UsMhU=.2513fc27-65e4-482e-ae9a-dd9fc41ececf@github.com>

On Fri, 10 Nov 2023 11:20:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JTabbedPane scroll button direction was incorrect because the widget type returned while painting the arrow was `SPINNER_ARROW_BUTTON`. Added the condition check for JTabbedPane before returning the widget type and based on the tab placement set by user, appropriate widget type is returned.
> 
> Tested the CI jobs against the fix and it was green. Link attached in JBS.

Looks good to me.

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16601#pullrequestreview-1743967426

From aivanov at openjdk.org  Wed Nov 22 12:19:14 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Nov 2023 12:19:14 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <DDzRuWuC2JPlDfTe4K9DDp6u4UuGnurY9rHh6dnCsf4=.c1c9857a-a8e2-4ca0-9ae7-b779918fa117@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
 <DDzRuWuC2JPlDfTe4K9DDp6u4UuGnurY9rHh6dnCsf4=.c1c9857a-a8e2-4ca0-9ae7-b779918fa117@github.com>
Message-ID: <c_XE2kMmjBGfb0orqghKEUVV4wV_aZfeCN621fX_p4o=.5bd5eef3-63ba-4a14-8823-99637f4ec99b@github.com>

On Wed, 22 Nov 2023 07:04:01 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2108:
>> 
>>> 2106:                         paintCell(g, cellRect, row, column);
>>> 2107:                     }
>>> 2108:                     cellRect.x += columnWidth;
>> 
>> This is weird? if we paint columns in right-to-left order, x should decrease.
>
> Here, we are painting from left-to-right order by starting with last column. It is only a convention, I guess painting this way is more simple that to actually paint from `right-to-left`. Here for both the orientations, we are painting from left-to-right, only difference is how we pick the columns.

Okay? So, you changed the painting order as well, it now paints from the last column to the first in the right-to-left orientation, does it? This is why the code inside the loop is the same now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401959619

From aivanov at openjdk.org  Wed Nov 22 12:23:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Nov 2023 12:23:13 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <MWKb1ujvllmtm_CLi5XD35NkBnB5hjff246dkzzcaXQ=.7b5f89f1-2186-42d9-bdb4-1db1c111e406@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
 <MWKb1ujvllmtm_CLi5XD35NkBnB5hjff246dkzzcaXQ=.7b5f89f1-2186-42d9-bdb4-1db1c111e406@github.com>
Message-ID: <Mgxj6LaWPV0SV8Z5onwljtMTEjkWFreYHGjc-EOxZzc=.758d6d4a-7093-488f-9a00-76b8d24033e2@github.com>

On Wed, 22 Nov 2023 06:42:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2031:
>> 
>>> 2029:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMin);
>>> 2030:         } else {
>>> 2031:             damagedArea.x = SwingUtilities2.getXPosInRightToLeft(table, cMax);
>> 
>> The method name `getXPosInRightToLeft` is confusing when you call it for the *left-to-right case*?
>
> Yeah, any suggestions?

Not yet? I don't fully grasp the meaning to suggest a better name. A generic `adjustX` would be less confusing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1401963215

From aivanov at openjdk.org  Wed Nov 22 12:45:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Nov 2023 12:45:09 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <CiZAb19G2TLwLKALb3mNvDICaS1usoGm9IfaI-BSI6o=.34ae7371-ee3b-4507-b187-73b84d796018@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
 <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>
 <CiZAb19G2TLwLKALb3mNvDICaS1usoGm9IfaI-BSI6o=.34ae7371-ee3b-4507-b187-73b84d796018@github.com>
Message-ID: <vcU0eFx17JRy9I3k8q0QHdTyuvK-n7WK8vLIkY-2DRY=.1ab74d9c-5dd5-4a7e-94d4-f1f680a03fb9@github.com>

On Wed, 22 Nov 2023 05:37:55 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> For some reasons when I used the `current directory i.e. scratch`, test failed in my local machine. `String tmpDir = System.getProperty(".");`

How does it fail?  
Is it because `System.getProperty(".")` returns `null`? The property `"."` doesn't exist, does it?

Use `new File(".")` which resolves to the current directory. Alternatively, remove references to paths, just create directories and files, they will be created in the current directory if you don't specify an absolute path.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1401989557

From aivanov at openjdk.org  Wed Nov 22 13:39:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Nov 2023 13:39:10 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <7X7jAl_s-2jWdDzpLdj1eFdEg7Ex5H0yfpWZFtozWwQ=.63daa618-e2d2-418a-be85-eae9ce0f153b@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <GVM9j4TqcBEcX5-G-YsV3AFu41_Bel8Ilb-epLq5k_0=.9ac66d68-75cc-4ed2-8bf2-4e06f23fd462@github.com>
 <7X7jAl_s-2jWdDzpLdj1eFdEg7Ex5H0yfpWZFtozWwQ=.63daa618-e2d2-418a-be85-eae9ce0f153b@github.com>
Message-ID: <3U9DSvzjKOJ3UPTIX2OBz294bM4XT3W3nQ10Gyh-UPE=.338957b8-bd87-4d03-99dc-1da2c21b6651@github.com>

On Thu, 16 Nov 2023 05:14:21 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 46:
>> 
>>> 44:  * @run main TestFileChooserSingleDirectorySelection
>>> 45:  */
>>> 46: 
>> 
>> I don't know why it was necessary to move all around all the above lines.
>> And whilst import java.io sorts after java.awt, it is long standing convention that the "core"
>> packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones. This is true of product source as well as tests.
>> So you should just undo all of the above except for adding the new bug id.
>
> Updated.

> And whilst import java.io sorts after java.awt, it is long standing convention that the "core"
> packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones. This is true of product source as well as tests.

@prrace This is the first time I hear this. In all the classes I've seen in AWT and Swing, the imports are sorted alphabetically with `java.io` after `java.awt`.

I just looked at [`JComponent`](https://github.com/openjdk/jdk/blob/5e818318eac8cda7d42b599dc7d7d44e5c299a9f/src/java.desktop/share/classes/javax/swing/JComponent.java#L54-L61), [`Component`](https://github.com/openjdk/jdk/blob/5e818318eac8cda7d42b599dc7d7d44e5c299a9f/src/java.desktop/share/classes/java/awt/Component.java#L61-L65), [Font](https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/java/awt/Font.java#L32-L38), and

https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/sun/font/FontManager.java#L28-L30

https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/sun/font/Font2D.java#L28-L36

[Sun/Oracle Code Conventions for Java Programming Language](https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html#277) say nothing about the order of imports. (The HTML version has absolutely broken formatting now.) [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html#s3.3-import-statements) states, <q cite="https://google.github.io/styleguide/javaguide.html#s3.3-import-statements">?the imported names appear in ASCII sort order.</q>

Andreas Lundblad's draft for [Java Style Guidelines](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-import-statements), which is more or less followed by the OpenJDK project, defines the following order:

> Import statements should be sorted?
>
> *  ?primarily by non-static / static with non-static imports first.
> * ?secondarily by package origin according to the following order
>   * `java` packages
>   * `javax` packages
>   * external packages (e.g. `org.xml`)
>   * internal packages (e.g. `com.sun`)
> * ?tertiary by package and class identifier in lexicographical order

[Andreas](https://github.com/aioobe) opened [PR 14](https://github.com/openjdk/guide/pull/14) to incorporate it into OpenJDK Developers' Guide, but there are objections to making the Java Code Conventions part of the developers' guide.

I believe it's not even the first time such a discussion happens in the clientlibs. There are no guidelines?

Personally, I think putting `java.awt` classes above `java.io` or `java.util` makes perfect sense for clientlibs classes ? it is what we care the most, it is what we're developing and maintaining, so `java.awt` is more relevant to us. And it automatically sorts this way in IDE; manually sorting imports is tedious and error-prone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1402059540

From aivanov at openjdk.org  Wed Nov 22 13:54:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Nov 2023 13:54:04 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <3U9DSvzjKOJ3UPTIX2OBz294bM4XT3W3nQ10Gyh-UPE=.338957b8-bd87-4d03-99dc-1da2c21b6651@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <GVM9j4TqcBEcX5-G-YsV3AFu41_Bel8Ilb-epLq5k_0=.9ac66d68-75cc-4ed2-8bf2-4e06f23fd462@github.com>
 <7X7jAl_s-2jWdDzpLdj1eFdEg7Ex5H0yfpWZFtozWwQ=.63daa618-e2d2-418a-be85-eae9ce0f153b@github.com>
 <3U9DSvzjKOJ3UPTIX2OBz294bM4XT3W3nQ10Gyh-UPE=.338957b8-bd87-4d03-99dc-1da2c21b6651@github.com>
Message-ID: <Cho7kCMDJ74Y60Yre0CIC9YPC5HXqQlAN5XdGXQ0X8k=.04add339-89e8-4824-98d5-3f9b5535b1a5@github.com>

On Wed, 22 Nov 2023 13:36:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Updated.
>
>> And whilst import java.io sorts after java.awt, it is long standing convention that the "core"
>> packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones. This is true of product source as well as tests.
> 
> @prrace This is the first time I hear this. In all the classes I've seen in AWT and Swing, the imports are sorted alphabetically with `java.io` after `java.awt`.
> 
> I just looked at [`JComponent`](https://github.com/openjdk/jdk/blob/5e818318eac8cda7d42b599dc7d7d44e5c299a9f/src/java.desktop/share/classes/javax/swing/JComponent.java#L54-L61), [`Component`](https://github.com/openjdk/jdk/blob/5e818318eac8cda7d42b599dc7d7d44e5c299a9f/src/java.desktop/share/classes/java/awt/Component.java#L61-L65), [Font](https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/java/awt/Font.java#L32-L38), and
> 
> https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/sun/font/FontManager.java#L28-L30
> 
> https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/sun/font/Font2D.java#L28-L36
> 
> [Sun/Oracle Code Conventions for Java Programming Language](https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html#277) say nothing about the order of imports. (The HTML version has absolutely broken formatting now.) [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html#s3.3-import-statements) states, <q cite="https://google.github.io/styleguide/javaguide.html#s3.3-import-statements">?the imported names appear in ASCII sort order.</q>
> 
> Andreas Lundblad's draft for [Java Style Guidelines](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-import-statements), which is more or less followed by the OpenJDK project, defines the following order:
> 
>> Import statements should be sorted?
>>
>> *  ?primarily by non-static / static with non-static imports first.
>> * ?secondarily by package origin according to the following order
>>   * `java` packages
>>   * `javax` packages
>>   * external packages (e.g. `org.xml`)
>>   * internal packages (e.g. `com.sun`)
>> * ?tertiary by package and class identifier in lexicographical order
> 
> [Andreas](https://github.com/aioobe) opened [PR 14](https://github.com/openjdk/guide/pull/14) to incorporate it into OpenJDK Developers' Guide, but there are objections to making the Java Code Conventions p...

> I don't know why it was necessary to move all around all the above lines.

@prrace I nearly always ask to move the jtreg tags to the class declaration, especially for new tests. When you open the test file in IDE, the copyright block above imports is collapsed, so is the jtreg tags if they're placed above the imports.

If the jtreg tags are placed in a comment that precedes the class declaration, after the imports, they're not collapsed ? you can see them right away without scrolling or clicking. I consider the jtreg tags quite relevant to see them easily.

Most older tests place the jtreg tags above the imports; it could've been the requirement or limitation of jtreg at that time. It's not a limitation any more.

As for moving the jtreg tags in existing tests when the test is modified, I also do it occasionally for the reasons outlined above: the jtreg tags describe the test and belong to the class declaration, akin a javadoc comment. (Yet I am against using the javadoc syntax, starting with two asterisks, for the jtreg tasks because it is not a javadoc and because it removes the IDE warnings for the unknown javadoc tasks.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1402082665

From aivanov at openjdk.org  Wed Nov 22 13:58:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 22 Nov 2023 13:58:09 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v6]
In-Reply-To: <BmP07Ynj26JHjCpvbuo4-Hmm9ATBOtK3xHcIQntm-Ik=.0ea1c8b1-4b99-4519-a68f-42bab94ab1e1@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <FkAshhSc0ByKS7iPaVk58onv775Hjyyec4qK_XPgC5g=.2e307a03-a483-4658-b8b3-5e349dd87d56@github.com>
 <Lba6k_CS1BGLHLFLsRk4GFdnu0tjuM1cra5ivKZlDgg=.a7cfbfaf-e323-4383-acda-1dfc1dbcf9d8@github.com>
 <BmP07Ynj26JHjCpvbuo4-Hmm9ATBOtK3xHcIQntm-Ik=.0ea1c8b1-4b99-4519-a68f-42bab94ab1e1@github.com>
Message-ID: <D4TIU_tKTNP_ou8ZFBYEVU6ey9QQH761Qoo0ECaQCw0=.a3e0bb84-09a6-45c5-91dc-254106154015@github.com>

On Wed, 22 Nov 2023 03:27:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/swing/JProgressBar/TestProgressBarBorder.java line 28:
>> 
>>> 26: import java.lang.reflect.InvocationTargetException;
>>> 27: import java.awt.Graphics;
>>> 28: import java.awt.image.BufferedImage;
>> 
>> IDEA at my end disagrees with the current sorting order:
>> Suggestion:
>> 
>> import java.awt.Graphics;
>> import java.awt.image.BufferedImage;
>> import java.io.File;
>> import java.io.IOException;
>
> I know that the sorting order is not correct but I received a comment on my other PR https://github.com/openjdk/jdk/pull/16674#discussion_r1394632505 which suggests `it is long standing convention that the "core"
> packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones.` That's the reason I didn't sorted the imports.

> I know that the sorting order is not correct but I received a comment on my other PR [#16674 (comment)](https://github.com/openjdk/jdk/pull/16674#discussion_r1394632505) which suggests `it is long standing convention that the "core" packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones.` That's the reason I didn't sorted the imports.

Let us [discuss it there](https://github.com/openjdk/jdk/pull/16674#discussion_r1402059540). This is news to me. I am for sorting the imports alphabetically ? an IDE does it perfectly and inserts new imports into the correct place, managing the list of imports manually is *tedious* and error-prone.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16467#discussion_r1402090399

From tr at openjdk.org  Wed Nov 22 14:35:41 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 14:35:41 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v7]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <6BDCrInQGxpqjusJzWtyR8AERum6bWd_vXELlwXq05k=.f912e164-9f19-41ec-a9aa-9be32c0e58c3@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/10b199bf..188a7c9d

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

  Stats: 488 lines in 6 files changed: 214 ins; 269 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16374/head:pull/16374

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

From tr at openjdk.org  Wed Nov 22 14:35:42 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 14:35:42 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <c_XE2kMmjBGfb0orqghKEUVV4wV_aZfeCN621fX_p4o=.5bd5eef3-63ba-4a14-8823-99637f4ec99b@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
 <DDzRuWuC2JPlDfTe4K9DDp6u4UuGnurY9rHh6dnCsf4=.c1c9857a-a8e2-4ca0-9ae7-b779918fa117@github.com>
 <c_XE2kMmjBGfb0orqghKEUVV4wV_aZfeCN621fX_p4o=.5bd5eef3-63ba-4a14-8823-99637f4ec99b@github.com>
Message-ID: <BahhdmtkGDFLPkhR-hP5GU51wMCA0oUTEveabaXtz-k=.eb2ff991-c0d3-437e-97d3-40a8f31046aa@github.com>

On Wed, 22 Nov 2023 12:16:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Here, we are painting from left-to-right order by starting with last column. It is only a convention, I guess painting this way is more simple that to actually paint from `right-to-left`. Here for both the orientations, we are painting from left-to-right, only difference is how we pick the columns.
>
> Okay? So, you changed the painting order as well, it now paints from the last column to the first in the right-to-left orientation, does it? This is why the code inside the loop is the same now.

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1402153064

From tr at openjdk.org  Wed Nov 22 14:39:14 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 14:39:14 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
Message-ID: <exOnzwvzKT1uQTMS2NUY4iAGWUsvGzDqn1fpr9i-KrQ=.0cea5748-38e9-4093-a481-83c517deb158@github.com>

On Wed, 8 Nov 2023 08:49:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
>> similar to how header is painted
> 
> Can you please point to the code where the header is painted similarly?

@prsadhuk @aivanov-jdk I have update the `JTable.getCellRect()` method as to consider the offset for RTL orientation, it works well and with minimal changes in Table UI classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/16374#issuecomment-1822889740

From tr at openjdk.org  Wed Nov 22 14:39:17 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 14:39:17 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
Message-ID: <buE5P2cXULDrKjFJrl2A3aQid2t1EF_3yqBtcRxOY5A=.38fa5de8-c4a6-48db-9086-3a5abd1e8526@github.com>

On Tue, 21 Nov 2023 15:08:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/sun/swing/SwingUtilities2.java line 2371:
> 
>> 2369:             return table.getWidth();
>> 2370:         }
>> 2371:         return table.getParent().getWidth();
> 
> The condition `table != null` seems redundant ? if it's `null`, the expression `table.getParent()` in the return statement throws NPE.

Not applicable now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1402161989

From tr at openjdk.org  Wed Nov 22 14:43:14 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 22 Nov 2023 14:43:14 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v6]
In-Reply-To: <Mgxj6LaWPV0SV8Z5onwljtMTEjkWFreYHGjc-EOxZzc=.758d6d4a-7093-488f-9a00-76b8d24033e2@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <1HHDB71oHvrjeV6MFc1C_B6pev0TkXsuyUKafS5VywE=.a15ee86a-6713-487f-a706-d03b74f89745@github.com>
 <X9RJJjvw4sFNEyK_m8l4xximlmxRkydcgJ3M3EiE8C0=.e90e398d-de74-48ad-afee-79a6b87c31fc@github.com>
 <MWKb1ujvllmtm_CLi5XD35NkBnB5hjff246dkzzcaXQ=.7b5f89f1-2186-42d9-bdb4-1db1c111e406@github.com>
 <Mgxj6LaWPV0SV8Z5onwljtMTEjkWFreYHGjc-EOxZzc=.758d6d4a-7093-488f-9a00-76b8d24033e2@github.com>
Message-ID: <YtjlBeiT924nQA7xU2acPld-EYSr0MYYqThUopJHNOU=.9c7abc2f-d6c7-4dc2-90bb-24e5bf15b372@github.com>

On Wed, 22 Nov 2023 12:20:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yeah, any suggestions?
>
> Not yet? I don't fully grasp the meaning to suggest a better name. A generic `adjustX` would be less confusing.

Not applicable now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1402168627

From duke at openjdk.org  Wed Nov 22 16:34:19 2023
From: duke at openjdk.org (Alec Su)
Date: Wed, 22 Nov 2023 16:34:19 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: <QdTUrHyFcxWL5K7HTemAPhM1tr4PYNaFjGUDK2pa5Iw=.209644ed-2290-4178-b9df-3cb7b599830b@github.com>
References: <vd2LqvLzE0nciwRwxVDV1AmfwuuKYzfU0q5DNPvE2jQ=.22c27bee-4a86-4d2f-84af-5bb18575ec14@github.com>
 <SYsli-ZJgUlO5TYmIbJsQGwAwvA_iiHelS_9-Mv9DYU=.de73135b-5c0b-451e-abc2-32c9dd01aa9a@github.com>
 <QdTUrHyFcxWL5K7HTemAPhM1tr4PYNaFjGUDK2pa5Iw=.209644ed-2290-4178-b9df-3cb7b599830b@github.com>
Message-ID: <GOP1_zSb0DCgTzKtfZywMsgZfRtAnEMJjK1hGzFx11U=.fa194883-0c2a-4d69-b1e9-11d6f09521b7@github.com>

On Mon, 30 Oct 2023 21:30:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> Alec Su has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code cleanup
>
>> It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data
>> However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation.
> 
> 
> This seems to be documented by Microsoft only in the most obscure fashion.
> 
> If you look at the doc for midiOutPrepareHeader
> https://learn.microsoft.com/en-us/previous-versions/dd798477(v=vs.85)
> it says "Before calling the function, set the lpData, dwBufferLength, and dwFlags members of the [MIDIHDR](https://learn.microsoft.com/en-us/previous-versions/dd798449(v=vs.85)) structure"
> 
> So no mention of dwBytesRecorded.
> 
> WAVEHDR is a very similar struct to MIDIHDR and if you look at this WAVEHDR doc it says
> 
> https://learn.microsoft.com/en-us/previous-versions/dd743837(v=vs.85)
> 
>     dwBytesRecorded
>     When the header is used in input, specifies how much data is in the buffer.
> 
> So I infer the same is true for MIDI
> 
> Therefore dwBytesRecorded is only used for input and dwBufferLength is what's important for output.

@prrace @mrserb Thank you very much.

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

PR Comment: https://git.openjdk.org/jdk/pull/16399#issuecomment-1823098255

From prr at openjdk.org  Wed Nov 22 19:01:06 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 22 Nov 2023 19:01:06 GMT
Subject: RFR: 8320057: [macos14]
 javax/swing/JToolTip/4846413/bug4846413.java: Tooltip has not been found!
In-Reply-To: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
References: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
Message-ID: <kf3Wm_ca-lCZNMEkZMgtjw5GZkhoCgFze5miFjTB-Cg=.13b9d394-2700-47e7-a089-7ea1bb8885d7@github.com>

On Wed, 22 Nov 2023 08:46:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test failing on macos14 citing "ToolTip not found"...Investigation shows that the mouse is not moved when invoked 1st time to desired location on screen causing tooltip to not show...However, subsequent runs of the same test without any change causes it to pass every time.
> Workaround is proposed to check if running on 14.x, then invoke a dummy mouse movement to same location which causes the test to pass for several iterations in macos14 environment.

I don't think this is a good idea. We aren't interested in just making the test "pass".
We need to understand what changed. If necessary it could end up in a bug report to Apple.

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

PR Comment: https://git.openjdk.org/jdk/pull/16776#issuecomment-1823319467

From prr at openjdk.org  Wed Nov 22 22:44:19 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 22 Nov 2023 22:44:19 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
Message-ID: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>

Many printing tests do not have the @printer keyword. This adds them to those that need it.
I also found one test that has nothing to do with printing in the print folder and moved it out.

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

Commit messages:
 - 8320608

Changes: https://git.openjdk.org/jdk/pull/16785/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320608
  Stats: 232 lines in 142 files changed: 133 ins; 20 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/16785.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16785/head:pull/16785

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

From honkar at openjdk.org  Thu Nov 23 00:26:06 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 23 Nov 2023 00:26:06 GMT
Subject: RFR: 8320057: [macos14]
 javax/swing/JToolTip/4846413/bug4846413.java: Tooltip has not been found!
In-Reply-To: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
References: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
Message-ID: <RXNBftqbYuVeEj8PYeQ1wpOTA1-AlQG06yecKhzdK3w=.06458f8e-b7d5-4a6a-9242-bca42ed9c3d8@github.com>

On Wed, 22 Nov 2023 08:46:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test failing on macos14 citing "ToolTip not found"...Investigation shows that the mouse is not moved when invoked 1st time to desired location on screen causing tooltip to not show...However, subsequent runs of the same test without any change causes it to pass every time.
> Workaround is proposed to check if running on 14.x, then invoke a dummy mouse movement to same location which causes the test to pass for several iterations in macos14 environment.

test/jdk/javax/swing/JToolTip/4846413/bug4846413.java line 79:

> 77:                 String version = System.getProperty("os.version", "");
> 78:                 if (version.startsWith("14.")) {
> 79:                     robot.mouseMove(movePoint.x, movePoint.y);

Adding to Phil's point, version specific test fixes would require to be removed and/or reworked if the issue gets fixed on latest macOS update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16776#discussion_r1402819149

From abhiscxk at openjdk.org  Thu Nov 23 05:11:07 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Nov 2023 05:11:07 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <vcU0eFx17JRy9I3k8q0QHdTyuvK-n7WK8vLIkY-2DRY=.1ab74d9c-5dd5-4a7e-94d4-f1f680a03fb9@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
 <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>
 <CiZAb19G2TLwLKALb3mNvDICaS1usoGm9IfaI-BSI6o=.34ae7371-ee3b-4507-b187-73b84d796018@github.com>
 <vcU0eFx17JRy9I3k8q0QHdTyuvK-n7WK8vLIkY-2DRY=.1ab74d9c-5dd5-4a7e-94d4-f1f680a03fb9@github.com>
Message-ID: <08NHlysHECIa2NzWIM2_IsZMxGBAjB8sUl5AIhxK4aQ=.e528a72c-d49f-4582-9466-80b762cb15ba@github.com>

On Wed, 22 Nov 2023 12:42:52 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> How does it fail? Is it because `System.getProperty(".")` returns `null`? The property `"."` doesn't exist, does it?

No, temp files and directories are created in `scratch` directory. But the files gets deselected after selection which returns as no file selected and test failed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1402920829

From alanb at openjdk.org  Thu Nov 23 07:06:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Nov 2023 07:06:04 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
Message-ID: <-qqvX2JKzr3-eQ_FNsovChX5aJjqQaqbewiVgvCamM0=.644272b2-55b3-4d32-8e57-7de1f9ec5590@github.com>

On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Many printing tests do not have the @printer keyword. This adds them to those that need it.
> I also found one test that has nothing to do with printing in the print folder and moved it out.

test/jdk/TEST.ROOT line 15:

> 13: #
> 14: # Notes on "client" keywords : headful sound printer 2d dnd multimon 
> 15: # ==================================================================

The notes reads well but they're notes for "2d" and "dnd". The heading hints that there will be information on these keywords.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1402974534

From aivanov at openjdk.org  Thu Nov 23 09:45:11 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 09:45:11 GMT
Subject: RFR: 8224261: JProgressBar always with border painted around it
 [v7]
In-Reply-To: <8Sictv3wzhD4_Td2c3wSjeqR-E9muKUk_GLJCRCjgIA=.0a4da67b-45c6-4123-a1b7-ba1cab35cb10@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
 <8Sictv3wzhD4_Td2c3wSjeqR-E9muKUk_GLJCRCjgIA=.0a4da67b-45c6-4123-a1b7-ba1cab35cb10@github.com>
Message-ID: <8Xmg3c7FTDI1q1UuhPyrBeqSDVD493s-UlacxZ6295k=.8ae76794-0e0f-4590-ace3-12312c42b081@github.com>

On Wed, 22 Nov 2023 04:25:38 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
>> 
>> CI jobs are green after the fix. Links attached to JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fix

Looks good to me.

I would sort the imports though.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16467#pullrequestreview-1744485512

From aivanov at openjdk.org  Thu Nov 23 11:03:21 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 11:03:21 GMT
Subject: RFR: 8294156: Demo positioning of multiple test windows [v2]
In-Reply-To: <k7ILJCRpJLt2pcL-zuX3srLCkjr3XJoTTyAe6TDeWp0=.e797041a-64ad-40b8-a681-bbdca5ae058d@github.com>
References: <Rtkhmmnm1KAMWnYhCaXV3_Dg57WmVYDVN-iXzxcqwAM=.4208ddf5-9834-4752-a302-b0e8a1978dd6@github.com>
 <k7ILJCRpJLt2pcL-zuX3srLCkjr3XJoTTyAe6TDeWp0=.e797041a-64ad-40b8-a681-bbdca5ae058d@github.com>
Message-ID: <C_QCTUtG4IJ7Zzz3P8YopRWoWuDRwVZgFVYLJKx1vqc=.66daa054-93d5-4162-b419-8e8f899d6abc@github.com>

On Wed, 13 Sep 2023 18:50:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The manual test frame does not provide any layout managers for test windows, the user has to implement one. This demonstrates how to position a several test UI windows.
>> 
>> We may include some implementations into the manual test framework in the future.
>> 
>> **This PR is not meant to be integrated.** It just demonstrates the feature of adding multiple test windows to `PassFailJFrame` which is reviewed in #15665.
>> 
>> To play around, you can checkout the PR branch using the commands that bots add.
>> 
>> Path to the tests: `test/jdk/java/awt/Window/8294156`.
>> 
>> Alternatively, you can checkout directly from my fork:
>> 
>> 
>> git fetch https://github.com/aivanov-jdk/jdk.git demo-manyTestWindows:demo-manyTestWindows
>> git checkout demo-manyTestWindows
>> 
>> 
>> To update your local branch, use:
>> 
>> git checkout demo-manyTestWindows
>> git pull https://github.com/aivanov-jdk/jdk.git demo-manyTestWindows
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8294156: Additional layouts for vertically positioned test windows

This pull request did its job, it's time to close it.

Simple one-row or -column layouts will be provided under [JDK-8317116](https://bugs.openjdk.org/browse/JDK-8317116): *Provide layouts for multiple test UI in `PassFailJFrame`*.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15721#issuecomment-1824225527

From aivanov at openjdk.org  Thu Nov 23 11:03:23 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 11:03:23 GMT
Subject: Withdrawn: 8294156: Demo positioning of multiple test windows
In-Reply-To: <Rtkhmmnm1KAMWnYhCaXV3_Dg57WmVYDVN-iXzxcqwAM=.4208ddf5-9834-4752-a302-b0e8a1978dd6@github.com>
References: <Rtkhmmnm1KAMWnYhCaXV3_Dg57WmVYDVN-iXzxcqwAM=.4208ddf5-9834-4752-a302-b0e8a1978dd6@github.com>
Message-ID: <TVDUfJxYDwBDZ0Ksci_ZcOPVmBVd5iolMZslO0NvvF0=.1336d7ae-2383-4f21-b634-6750b2a83d10@github.com>

On Wed, 13 Sep 2023 14:42:59 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The manual test frame does not provide any layout managers for test windows, the user has to implement one. This demonstrates how to position a several test UI windows.
> 
> We may include some implementations into the manual test framework in the future.
> 
> **This PR is not meant to be integrated.** It just demonstrates the feature of adding multiple test windows to `PassFailJFrame` which is reviewed in #15665.
> 
> To play around, you can checkout the PR branch using the commands that bots add.
> 
> Path to the tests: `test/jdk/java/awt/Window/8294156`.
> 
> Alternatively, you can checkout directly from my fork:
> 
> 
> git fetch https://github.com/aivanov-jdk/jdk.git demo-manyTestWindows:demo-manyTestWindows
> git checkout demo-manyTestWindows
> 
> 
> To update your local branch, use:
> 
> git checkout demo-manyTestWindows
> git pull https://github.com/aivanov-jdk/jdk.git demo-manyTestWindows

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/15721

From aivanov at openjdk.org  Thu Nov 23 11:04:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 11:04:05 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <08NHlysHECIa2NzWIM2_IsZMxGBAjB8sUl5AIhxK4aQ=.e528a72c-d49f-4582-9466-80b762cb15ba@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
 <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>
 <CiZAb19G2TLwLKALb3mNvDICaS1usoGm9IfaI-BSI6o=.34ae7371-ee3b-4507-b187-73b84d796018@github.com>
 <vcU0eFx17JRy9I3k8q0QHdTyuvK-n7WK8vLIkY-2DRY=.1ab74d9c-5dd5-4a7e-94d4-f1f680a03fb9@github.com>
 <08NHlysHECIa2NzWIM2_IsZMxGBAjB8sUl5AIhxK4aQ=.e528a72c-d49f-4582-9466-80b762cb15ba@github.com>
Message-ID: <Rh6xT9G5F3AKXcHerywrRz3A4JBILOupZ1Ek1tmVDLA=.c56d1e36-a732-4ec4-a559-5b820b322823@github.com>

On Thu, 23 Nov 2023 05:08:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> But the files gets deselected after selection which returns as no file selected and test failed.

How is it? It sounds like magic? The working directory shouldn't matter; if it does, the test isn't as stable as it should be.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1403224357

From abhiscxk at openjdk.org  Thu Nov 23 11:56:12 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Nov 2023 11:56:12 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <Rh6xT9G5F3AKXcHerywrRz3A4JBILOupZ1Ek1tmVDLA=.c56d1e36-a732-4ec4-a559-5b820b322823@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
 <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>
 <CiZAb19G2TLwLKALb3mNvDICaS1usoGm9IfaI-BSI6o=.34ae7371-ee3b-4507-b187-73b84d796018@github.com>
 <vcU0eFx17JRy9I3k8q0QHdTyuvK-n7WK8vLIkY-2DRY=.1ab74d9c-5dd5-4a7e-94d4-f1f680a03fb9@github.com>
 <08NHlysHECIa2NzWIM2_IsZMxGBAjB8sUl5AIhxK4aQ=.e528a72c-d49f-4582-9466-80b762cb15ba@github.com>
 <Rh6xT9G5F3AKXcHerywrRz3A4JBILOupZ1Ek1tmVDLA=.c56d1e36-a732-4ec4-a559-5b820b322823@github.com>
Message-ID: <CkKP7I-m1f-sxerCkDC02DKdOOtMU1oe9uMVRLcoFnE=.908bfc47-3070-42d8-b932-229286a3a707@github.com>

On Thu, 23 Nov 2023 11:01:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> How does it fail? Is it because `System.getProperty(".")` returns `null`? The property `"."` doesn't exist, does it?
>> 
>> No, temp files and directories are created in `scratch` directory. But the files gets deselected after selection which returns as no file selected and test failed.
>
>> But the files gets deselected after selection which returns as no file selected and test failed.
> 
> How is it? It sounds like magic? The working directory shouldn't matter; if it does, the test isn't as stable as it should be.

Surprise to me also. It failed every single time when temporary files are created in `scratch`. 

>The test isn't as stable as it should be.

Unable to trace what is missing in the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1403282851

From duke at openjdk.org  Thu Nov 23 13:07:22 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Thu, 23 Nov 2023 13:07:22 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with native
 libpipewire api
Message-ID: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>

This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

-------------

Commit messages:
 - 8320655: awt screencast robot spin and sync issues with native libpipewire api

Changes: https://git.openjdk.org/jdk/pull/16794/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16794&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320655
  Stats: 30 lines in 1 file changed: 27 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16794/head:pull/16794

PR: https://git.openjdk.org/jdk/pull/16794

From sgehwolf at openjdk.org  Thu Nov 23 13:24:05 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 23 Nov 2023 13:24:05 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
Message-ID: <py0cj-EtumKfO-z3m3R-vqBmHdUNnOe5U26cHorCj2s=.e4f61400-6ae3-4bc9-ac22-8859691a612c@github.com>

On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

@antbob Please trigger a test run of GHA. You should be able to do that in https://github.com/antbob/jdk/actions/workflows/main.yml (manual trigger). Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16794#issuecomment-1824430161

From abhiscxk at openjdk.org  Thu Nov 23 16:22:32 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 23 Nov 2023 16:22:32 GMT
Subject: Integrated: 8224261: JProgressBar always with border painted around it
In-Reply-To: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
References: <BRxOvkoUwRJvu0gyy7P1h0gBSg0CME1VoS7Ie4xHSjI=.4a742796-27aa-4ac0-a0ac-14b2df2210b6@github.com>
Message-ID: <L7hl1I-e49XdQXahYiMriuZTJhlIA010r-riXZ4xJkk=.b7f27f20-34a9-4743-b66d-6f8a6476b982@github.com>

On Thu, 2 Nov 2023 04:13:17 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JProgressBar is always painted with border irrespective of the value set via the API `setBorderPainted(boolean value)` in Synth (Nimbus and GTK) LAF. Proposed fix is to add a check before painting the component.
> 
> CI jobs are green after the fix. Links attached to JBS.

This pull request has now been integrated.

Changeset: cb95e393
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cb95e393b638d49a2ac07d3173f1ad7581176e7b
Stats:     114 lines in 2 files changed: 111 ins; 0 del; 3 mod

8224261: JProgressBar always with border painted around it

Reviewed-by: aivanov, dnguyen

-------------

PR: https://git.openjdk.org/jdk/pull/16467

From aivanov at openjdk.org  Thu Nov 23 17:09:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 17:09:07 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS
In-Reply-To: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
Message-ID: <kVPAfW-7IxPfv6tTeIzvOYRRD91uRhu2sxuEVglev9U=.30a49c44-4b05-423b-922d-86e3e817c11c@github.com>

On Tue, 21 Nov 2023 21:23:12 GMT, Phil Race <prr at openjdk.org> wrote:

> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
> a printer would give you null for the defaultTransform.
> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
> We have a test that would have caught it except that until recently the macOS printing implementation
> was swallowing exceptions it should not.

test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 26:

> 24: /*
> 25:  *
> 26:  * @bug 4276227 8320443

There's no `@test` tag, the test will not run without it.

Is it intentional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1403612371

From aivanov at openjdk.org  Thu Nov 23 17:27:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 17:27:17 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
Message-ID: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>

On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Many printing tests do not have the @printer keyword. This adds them to those that need it.
> I also found one test that has nothing to do with printing in the print folder and moved it out.

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/PrintJob/EdgeTest/EdgeTest.java line 30:

> 28:  * @summary Verifies that (0, 0) is the upper-left corner of the page, not
> 29:  *          the upper-left corner adjusted for the margins.
> 30:  * @author dpm

Suggestion:


Perhaps, remove the `@author` tag here too.

test/jdk/java/awt/PrintJob/RoundedRectTest/RoundedRectTest.java line 29:

> 27:  * @bug 4061440
> 28:  * @summary Checks that rounded rectangles print correctly.
> 29:  * @author dpm

Suggestion:

test/jdk/java/awt/print/PageFormat/SetOrient.java line 28:

> 26:  * @summary Confirm that the clip and transform of the Graphics2D is
> 27:  *          affected by the landscape orientation of the PageFormat.
> 28:  */

Since this test calls `pjob.print();`, it requires a printer. Indeed, it fails without a printer:


runner starting test: java/awt/print/PageFormat/SetOrient.html
runner finished test: java/awt/print/PageFormat/SetOrient.html
Failed. Execution failed: Applet thread threw exception:
        java.lang.RuntimeException: No print service found.
Test results: failed: 1

test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 30:

> 28: 
> 29: import java.awt.*;
> 30: import java.awt.print.*;

Could you expand the wildcard imports, please?

I would appreciate if you would add the jtreg tags *after* the imports.

test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 35:

> 33: {
> 34:    public static void main(String args[])
> 35:    {

Suggestion:

public class SmallPaperPrinting {
   public static void main(String[] args) {

Since you're reformatting the test source, it's better to follow the Java code style? throughout the entire source file.

test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 42:

> 40:      System.out.println("A passing test should catch a PrinterException");
> 41:      System.out.println("and should display \"Print error: (exception msg)\".");
> 42:      System.out.println("---------------------------------------------------\n");

According to these instructions, the test is to contain a set of `@test` tags:


/*
* @test
* @key printer
* @run main/othervm SmallPaperPrinting
*/

/*
 * @test
 * @key printer
 * @run main/othervm SmallPaperPrinting 1
 */

/*
 * @test
 * @key printer
 * @run main/othervm SmallPaperPrinting 2
 */


Otherwise, it won't run all the cases and no one will ever see these instructions.

For me, the test with the added `@test` tags as above prints an error message in the first two cases:

# id0.jtr
Print error:
Paper's imageable height is too small.
# id1.jtr
Print error:
Paper's imageable width is too small.


Yet it does not print any error message in the third case where `width=-1`, and **it does not fail**.

If I run it on a system without a printer, the test also *passes successfully*. Perhaps, we can ignore it as the `@key printer` ensures there's a printer the system.

Having said the above, this test requires its own bug to fix the test.

test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java line 29:

> 27:    @key printer
> 28:    @run main/manual WrongPaperPrintingTest
> 29:  */

It's minor but still, in majority of tests, the `@key` tag follows the `@bug` tag, and you mostly follow the convention in this PR. Keeping the order consistent helps scanning the test description with eyes quickly.

test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 30:

> 28:  * @key printer
> 29:  * @run main EmptyFill
> 30:  */

This test does not need a printer, it prints into a byte array and analyses the output. The test passes successfully on a system without a printer.

test/jdk/java/awt/print/PrinterJob/GetUserNameTest.java line 26:

> 24:  * @test
> 25:  * @bug 6197099
> 26:  * @key printer

The test works correctly without a printer, it prints the expected message:

SecurityException thrown as user.name permission not given


No other exceptions are thrown but the warnings that `SecurityManager` is deprecated.

test/jdk/java/awt/print/PrinterJob/MultiMonPrintDlgTest.java line 40:

> 38:  * @test
> 39:  * @bug 8138749
> 40:  * @key printer

Suggestion:

 * @key printer multimon

The test requires two monitors.

test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 26:

> 24: /**
> 25:  *
> 26:  * @bug 4884389 7183516

Is it intentional that there's no `@test` tag?

test/jdk/java/awt/print/PrinterJob/PrintTranslatedFont.java line 29:

> 27:  * @key printer
> 28:  * @summary Test that fonts with a translation print where they should.
> 29:  * @author prr

Suggestion:

test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 31:

> 29:  * @key printer
> 30:  * @run main/othervm PrinterDevice
> 31:  */

There's no `@test` tag, is it intentional?

Probably, you should remove this test from this PR because you're modifying in #16773.

test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest/PrinterDialogsModalityTest.html line 30:

> 28:   @key printer
> 29:   @summary check whether Print- and Page- dialogs are modal and correct window activated after their closing
> 30:   @author Your Name: area=PrinterJob.modality

Suggestion:

test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 25:

> 23: 
> 24: /*
> 25:  * @test 1.1 01/05/17

Suggestion:

 * @test

-------------

PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1746215963
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403233563
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403232953
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403250610
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403257236
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403254342
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403283083
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403301368
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403332726
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403341309
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403576760
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403595968
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403608444
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403613621
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403613833
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403616874

From aivanov at openjdk.org  Thu Nov 23 18:26:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 18:26:04 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
Message-ID: <aWLN1zj0YqrHwHu5ASRxhRjYXCpdeYOHW3E62B3qYUc=.788c464a-2c33-49b4-9317-7a0b0f15ef78@github.com>

On Thu, 23 Nov 2023 11:53:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Having said the above, this test requires its own bug to fix the test.

I submitted [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671): PageFormat/SmallPaperPrinting.java needs three sets of @test tags

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403654780

From aivanov at openjdk.org  Thu Nov 23 20:42:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 20:42:04 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
Message-ID: <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com>

On Thu, 23 Nov 2023 11:27:08 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> test/jdk/java/awt/print/PageFormat/SetOrient.java line 28:
> 
>> 26:  * @summary Confirm that the clip and transform of the Graphics2D is
>> 27:  *          affected by the landscape orientation of the PageFormat.
>> 28:  */
> 
> Since this test calls `pjob.print();`, it requires a printer. Indeed, it fails without a printer:
> 
> 
> runner starting test: java/awt/print/PageFormat/SetOrient.html
> runner finished test: java/awt/print/PageFormat/SetOrient.html
> Failed. Execution failed: Applet thread threw exception:
>         java.lang.RuntimeException: No print service found.
> Test results: failed: 1

I see `SetOrient.java` has its sibling `SetOrient.html` where you added `@key printer`.

Since both files contain all the tags except for `@test` in the .java file, you should not remove the `@run` tag from the .java file and add `@key printer` to it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403712328

From aivanov at openjdk.org  Thu Nov 23 20:59:04 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 20:59:04 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <Cho7kCMDJ74Y60Yre0CIC9YPC5HXqQlAN5XdGXQ0X8k=.04add339-89e8-4824-98d5-3f9b5535b1a5@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <GVM9j4TqcBEcX5-G-YsV3AFu41_Bel8Ilb-epLq5k_0=.9ac66d68-75cc-4ed2-8bf2-4e06f23fd462@github.com>
 <7X7jAl_s-2jWdDzpLdj1eFdEg7Ex5H0yfpWZFtozWwQ=.63daa618-e2d2-418a-be85-eae9ce0f153b@github.com>
 <3U9DSvzjKOJ3UPTIX2OBz294bM4XT3W3nQ10Gyh-UPE=.338957b8-bd87-4d03-99dc-1da2c21b6651@github.com>
 <Cho7kCMDJ74Y60Yre0CIC9YPC5HXqQlAN5XdGXQ0X8k=.04add339-89e8-4824-98d5-3f9b5535b1a5@github.com>
Message-ID: <50RQfFptQOxqTU70iCJQY0kJ_WVdzZ6o82P9Y3FaxAs=.d11f8a70-77b3-4e4d-a136-17921c9f29d2@github.com>

On Wed, 22 Nov 2023 13:50:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> And whilst import java.io sorts after java.awt, it is long standing convention that the "core"
>>> packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones. This is true of product source as well as tests.
>> 
>> @prrace This is the first time I hear this. In all the classes I've seen in AWT and Swing, the imports are sorted alphabetically with `java.io` after `java.awt`.
>> 
>> I just looked at [`JComponent`](https://github.com/openjdk/jdk/blob/5e818318eac8cda7d42b599dc7d7d44e5c299a9f/src/java.desktop/share/classes/javax/swing/JComponent.java#L54-L61), [`Component`](https://github.com/openjdk/jdk/blob/5e818318eac8cda7d42b599dc7d7d44e5c299a9f/src/java.desktop/share/classes/java/awt/Component.java#L61-L65), [Font](https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/java/awt/Font.java#L32-L38), and
>> 
>> https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/sun/font/FontManager.java#L28-L30
>> 
>> https://github.com/openjdk/jdk/blob/6ce0ebb858d3112f136e12d3ad595f805f6871a0/src/java.desktop/share/classes/sun/font/Font2D.java#L28-L36
>> 
>> [Sun/Oracle Code Conventions for Java Programming Language](https://www.oracle.com/java/technologies/javase/codeconventions-fileorganization.html#277) say nothing about the order of imports. (The HTML version has absolutely broken formatting now.) [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html#s3.3-import-statements) states, <q cite="https://google.github.io/styleguide/javaguide.html#s3.3-import-statements">?the imported names appear in ASCII sort order.</q>
>> 
>> Andreas Lundblad's draft for [Java Style Guidelines](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-import-statements), which is more or less followed by the OpenJDK project, defines the following order:
>> 
>>> Import statements should be sorted?
>>>
>>> *  ?primarily by non-static / static with non-static imports first.
>>> * ?secondarily by package origin according to the following order
>>>   * `java` packages
>>>   * `javax` packages
>>>   * external packages (e.g. `org.xml`)
>>>   * internal packages (e.g. `com.sun`)
>>> * ?tertiary by package and class identifier in lexicographical order
>> 
>> [Andreas](https://github.com/aioobe) opened [PR 14](https://github.com/openjdk/guide/pull/14) to incorporate it into OpenJDK Developers' Guide, but there are objecti...
>
>> I don't know why it was necessary to move all around all the above lines.
> 
> @prrace I nearly always ask to move the jtreg tags to the class declaration, especially for new tests. When you open the test file in IDE, the copyright block above imports is collapsed, so is the jtreg tags if they're placed above the imports.
> 
> If the jtreg tags are placed in a comment that precedes the class declaration, after the imports, they're not collapsed ? you can see them right away without scrolling or clicking. I consider the jtreg tags quite relevant to see them easily.
> 
> Most older tests place the jtreg tags above the imports; it could've been the requirement or limitation of jtreg at that time. It's not a limitation any more.
> 
> As for moving the jtreg tags in existing tests when the test is modified, I also do it occasionally for the reasons outlined above: the jtreg tags describe the test and belong to the class declaration, akin a javadoc comment. (Yet I am against using the javadoc syntax, starting with two asterisks, for the jtreg tasks because it is not a javadoc and because it removes the IDE warnings for the unknown javadoc tasks.)

> > And whilst import java.io sorts after java.awt, it is long standing convention that the "core"
> > packages (easily distinguished these days as those in the java.base module) are listed before the desktop / AWT / Swing ones. This is true of product source as well as tests.
> 
> @prrace This is the first time I hear this. In all the classes I've seen in AWT and Swing, the imports are sorted alphabetically with `java.io` after `java.awt`.

Today I've stumbled upon a few files where `java.io` and `java.util` come before `java.awt`, such as [`DialogOwnerTest.java`](https://github.com/openjdk/jdk/blob/9131a8f5f241b04c28a875fddb7a060cc9a3c252/test/jdk/java/awt/print/Dialog/DialogOwnerTest.java#L30-L32), [`CustomFont.java`](https://github.com/openjdk/jdk/blob/4a4fbbaaa97e22a8ec6dcc5d72a1ed43bc0b691e/test/jdk/java/awt/print/PrinterJob/CustomFont/CustomFont.java#L31-L32), [`DeviceScale.java`](https://github.com/openjdk/jdk/blob/7cb9e5821e0e5bcc483bc7c587ea921e9b515e77/test/jdk/java/awt/print/PrinterJob/DeviceScale.java#L31-L33),

https://github.com/openjdk/jdk/blob/3789983e89c9de252ef546a1b98a732a7d066650/test/jdk/java/awt/print/PrinterJob/DrawImage.java#L32-L36

It's a handful of files out of more than a hundred modified files in #16785; it doesn't look as a convention. Do wildcard imports even count?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1403718344

From aivanov at openjdk.org  Thu Nov 23 21:24:05 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 23 Nov 2023 21:24:05 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
Message-ID: <8Z9CPTdY9H-cW3OOeiUbOTcx80o08oKXnJEk8_OHfDI=.c55d95af-05d2-4981-8271-25204c271feb@github.com>

On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Many printing tests do not have the @printer keyword. This adds them to those that need it.
> I also found one test that has nothing to do with printing in the print folder and moved it out.

test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 29:

> 27:  * @key printer
> 28:  * @summary Font specified with face name loses style on printing
> 29:  * @run main/manual PrintRotatedText

Is it intentional that this test presumably runs another test ? `PrintRotatedText` ? instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1403735222

From simon at cjnash.com  Fri Nov 24 23:08:15 2023
From: simon at cjnash.com (Simon Nash)
Date: Fri, 24 Nov 2023 23:08:15 +0000
Subject: WindowsLookAndFeel change in JDK 22
Message-ID: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>

In the current EA build of JDK 22, selecting WindowsLookAndFeel on Windows 7 shows the same (ugly) UI style as WindowsClassicLookAndFeel.

With JDK 22 on Windows 10 and also with JDK 21 and below on both Windows 7 and Windows 10, this works as expected with different styles for WindowsLookAndFeel 
and WindowsClassicLookAndFeel.

Is this an intentional change in JDK 22 or a bug? If it is intentional, what was the reason?

Thanks, Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231124/d8d556ad/attachment.htm>

From philip.race at oracle.com  Fri Nov 24 23:30:38 2023
From: philip.race at oracle.com (Philip Race)
Date: Fri, 24 Nov 2023 15:30:38 -0800
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
Message-ID: <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>

I don't recall anything specific to this. Since you say "current EA 
build", does that imply very recently ?
My guess is that it is fall out from upgrading the Windows compiler + 
SDK and
we are no longer able to load the uxtheme library on Windows 7 needed 
for the WindowsL&F.
Note that it has been several years since anyone supported or tested 
Windows 7.
If you can confirm this started with JDK 22 b23 that would pretty much 
confirm the theory.

-phil.

On 11/24/23 3:08 PM, Simon Nash wrote:
> In the current EA build of JDK 22, selecting WindowsLookAndFeel on 
> Windows 7 shows the same (ugly) UI style as WindowsClassicLookAndFeel.
>
> With JDK 22 on Windows 10 and also with JDK 21 and below on both 
> Windows 7 and Windows 10, this works as expected with different styles 
> for WindowsLookAndFeel and WindowsClassicLookAndFeel.
>
> Is this an intentional change in JDK 22 or a bug? If it is 
> intentional, what was the reason?
>
> Thanks, Simon


From simon at cjnash.com  Sat Nov 25 10:09:51 2023
From: simon at cjnash.com (Simon Nash)
Date: Sat, 25 Nov 2023 10:09:51 +0000
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
Message-ID: <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>

Thanks for confirming that this change was not intentional. I am using the JDK 22 b24 EA build. When was the Windows compiler and SDK updated?

Simon

On 24/11/2023 23:30, Philip Race wrote:
> I don't recall anything specific to this. Since you say "current EA build", does that imply very recently ?
> My guess is that it is fall out from upgrading the Windows compiler + SDK and
> we are no longer able to load the uxtheme library on Windows 7 needed for the WindowsL&F.
> Note that it has been several years since anyone supported or tested Windows 7.
> If you can confirm this started with JDK 22 b23 that would pretty much confirm the theory.
>
> -phil.
>
> On 11/24/23 3:08 PM, Simon Nash wrote:
>> In the current EA build of JDK 22, selecting WindowsLookAndFeel on Windows 7 shows the same (ugly) UI style as WindowsClassicLookAndFeel.
>>
>> With JDK 22 on Windows 10 and also with JDK 21 and below on both Windows 7 and Windows 10, this works as expected with different styles for 
>> WindowsLookAndFeel and WindowsClassicLookAndFeel.
>>
>> Is this an intentional change in JDK 22 or a bug? If it is intentional, what was the reason?
>>
>> Thanks, Simon
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231125/7f49f8f2/attachment.htm>

From philip.race at oracle.com  Sat Nov 25 18:33:12 2023
From: philip.race at oracle.com (Philip Race)
Date: Sat, 25 Nov 2023 10:33:12 -0800
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
 <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
Message-ID: <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>

Re-read the last line of my previous email and you'll see the answer.

-phil.

On 11/25/23 2:09 AM, Simon Nash wrote:
> Thanks for confirming that this change was not intentional. I am using 
> the JDK 22 b24 EA build. When was the Windows compiler and SDK updated?
>
> Simon
>
> On 24/11/2023 23:30, Philip Race wrote:
>> I don't recall anything specific to this. Since you say "current EA 
>> build", does that imply very recently ?
>> My guess is that it is fall out from upgrading the Windows compiler + 
>> SDK and
>> we are no longer able to load the uxtheme library on Windows 7 needed 
>> for the WindowsL&F.
>> Note that it has been several years since anyone supported or tested 
>> Windows 7.
>> If you can confirm this started with JDK 22 b23 that would pretty 
>> much confirm the theory.
>>
>> -phil.
>>
>> On 11/24/23 3:08 PM, Simon Nash wrote:
>>> In the current EA build of JDK 22, selecting WindowsLookAndFeel on 
>>> Windows 7 shows the same (ugly) UI style as WindowsClassicLookAndFeel.
>>>
>>> With JDK 22 on Windows 10 and also with JDK 21 and below on both 
>>> Windows 7 and Windows 10, this works as expected with different 
>>> styles for WindowsLookAndFeel and WindowsClassicLookAndFeel.
>>>
>>> Is this an intentional change in JDK 22 or a bug? If it is 
>>> intentional, what was the reason?
>>>
>>> Thanks, Simon
>>
>>
>


From simon at cjnash.com  Sat Nov 25 21:46:32 2023
From: simon at cjnash.com (Simon Nash)
Date: Sat, 25 Nov 2023 21:46:32 +0000
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
 <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
 <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>
Message-ID: <bd3da4f6-a7c2-b00f-2c7d-f52fdd3b1e4f@cjnash.com>

I tried this with JDK 22 b22 and I got the same result. I will investigate further.

Simon

On 25/11/2023 18:33, Philip Race wrote:
> Re-read the last line of my previous email and you'll see the answer.
>
> -phil.
>
> On 11/25/23 2:09 AM, Simon Nash wrote:
>> Thanks for confirming that this change was not intentional. I am using the JDK 22 b24 EA build. When was the Windows compiler and SDK updated?
>>
>> Simon
>>
>> On 24/11/2023 23:30, Philip Race wrote:
>>> I don't recall anything specific to this. Since you say "current EA build", does that imply very recently ?
>>> My guess is that it is fall out from upgrading the Windows compiler + SDK and
>>> we are no longer able to load the uxtheme library on Windows 7 needed for the WindowsL&F.
>>> Note that it has been several years since anyone supported or tested Windows 7.
>>> If you can confirm this started with JDK 22 b23 that would pretty much confirm the theory.
>>>
>>> -phil.
>>>
>>> On 11/24/23 3:08 PM, Simon Nash wrote:
>>>> In the current EA build of JDK 22, selecting WindowsLookAndFeel on Windows 7 shows the same (ugly) UI style as WindowsClassicLookAndFeel.
>>>>
>>>> With JDK 22 on Windows 10 and also with JDK 21 and below on both Windows 7 and Windows 10, this works as expected with different styles for 
>>>> WindowsLookAndFeel and WindowsClassicLookAndFeel.
>>>>
>>>> Is this an intentional change in JDK 22 or a bug? If it is intentional, what was the reason?
>>>>
>>>> Thanks, Simon
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231125/1f2a53eb/attachment-0001.htm>

From philip.race at oracle.com  Sat Nov 25 22:57:06 2023
From: philip.race at oracle.com (Philip Race)
Date: Sat, 25 Nov 2023 14:57:06 -0800
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <bd3da4f6-a7c2-b00f-2c7d-f52fdd3b1e4f@cjnash.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
 <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
 <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>
 <bd3da4f6-a7c2-b00f-2c7d-f52fdd3b1e4f@cjnash.com>
Message-ID: <f8a23e32-e1df-4f48-928b-3d05fa2850b3@oracle.com>

I'm stumped then. Definitely not a problem with JDK 21u1 ?
https://download.java.net/java/GA/jdk21.0.1/415e3f918a1f4062a0074a2794853d0d/12/GPL/openjdk-21.0.1_windows-x64_bin.zip

Try some earlier JDK 22 build too - looks like b16 is the earliest that 
is available for download
https://download.java.net/java/early_access/jdk22/16/GPL/openjdk-22-ea+16_windows-x64_bin.zip

-phil.

On 11/25/23 1:46 PM, Simon Nash wrote:
> I tried this with JDK 22 b22 and I got the same result. I will 
> investigate further.
>
> Simon
>
> On 25/11/2023 18:33, Philip Race wrote:
>> Re-read the last line of my previous email and you'll see the answer.
>>
>> -phil.
>>
>> On 11/25/23 2:09 AM, Simon Nash wrote:
>>> Thanks for confirming that this change was not intentional. I am 
>>> using the JDK 22 b24 EA build. When was the Windows compiler and SDK 
>>> updated?
>>>
>>> Simon
>>>
>>> On 24/11/2023 23:30, Philip Race wrote:
>>>> I don't recall anything specific to this. Since you say "current EA 
>>>> build", does that imply very recently ?
>>>> My guess is that it is fall out from upgrading the Windows compiler 
>>>> + SDK and
>>>> we are no longer able to load the uxtheme library on Windows 7 
>>>> needed for the WindowsL&F.
>>>> Note that it has been several years since anyone supported or 
>>>> tested Windows 7.
>>>> If you can confirm this started with JDK 22 b23 that would pretty 
>>>> much confirm the theory.
>>>>
>>>> -phil.
>>>>
>>>> On 11/24/23 3:08 PM, Simon Nash wrote:
>>>>> In the current EA build of JDK 22, selecting WindowsLookAndFeel on 
>>>>> Windows 7 shows the same (ugly) UI style as 
>>>>> WindowsClassicLookAndFeel.
>>>>>
>>>>> With JDK 22 on Windows 10 and also with JDK 21 and below on both 
>>>>> Windows 7 and Windows 10, this works as expected with different 
>>>>> styles for WindowsLookAndFeel and WindowsClassicLookAndFeel.
>>>>>
>>>>> Is this an intentional change in JDK 22 or a bug? If it is 
>>>>> intentional, what was the reason?
>>>>>
>>>>> Thanks, Simon
>>>>
>>>>
>>>
>>
>>
>


From psadhukhan at openjdk.org  Mon Nov 27 08:13:04 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Nov 2023 08:13:04 GMT
Subject: RFR: 8225220: When the Tab Policy is checked,the scroll button
 direction displayed incorrectly.
In-Reply-To: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
References: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
Message-ID: <B9i0EqzpMoDUeRbpRqpRysKKSswPGNdW8Ve2WOFoiUY=.66fbae6d-e91f-4826-8e60-497317504db1@github.com>

On Fri, 10 Nov 2023 11:20:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JTabbedPane scroll button direction was incorrect because the widget type returned while painting the arrow was `SPINNER_ARROW_BUTTON`. Added the condition check for JTabbedPane before returning the widget type and based on the tab placement set by user, appropriate widget type is returned.
> 
> Tested the CI jobs against the fix and it was green. Link attached in JBS.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16601#pullrequestreview-1749850790

From psadhukhan at openjdk.org  Mon Nov 27 09:04:18 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 27 Nov 2023 09:04:18 GMT
Subject: Integrated: 8318113: CSS.BackgroundImage doesn't implement equals
In-Reply-To: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
References: <A14UosO52MDWjXNEXF-T63T1WmkYj1erjq_Ryc5RZzo=.cebef997-273f-4ec5-8f8e-009cf104e831@github.com>
Message-ID: <ptRWqi168m5WW1b8QJ2hJDYTIzfdT84gJZVFGR08UhQ=.80d2a044-00d1-4238-b227-ac2482c8d037@github.com>

On Fri, 10 Nov 2023 13:50:27 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSSBackgroundImage.equals() is implemented

This pull request has now been integrated.

Changeset: 12723688
Author:    Prasanta Sadhukhan <psadhukhan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/12723688ca49d379d43fd0fd0e55a28afe299687
Stats:     17 lines in 2 files changed: 16 ins; 0 del; 1 mod

8318113: CSS.BackgroundImage doesn't implement equals

Reviewed-by: aivanov, tr, prr

-------------

PR: https://git.openjdk.org/jdk/pull/16613

From simon at cjnash.com  Mon Nov 27 14:43:00 2023
From: simon at cjnash.com (Simon Nash)
Date: Mon, 27 Nov 2023 14:43:00 +0000
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <f8a23e32-e1df-4f48-928b-3d05fa2850b3@oracle.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
 <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
 <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>
 <bd3da4f6-a7c2-b00f-2c7d-f52fdd3b1e4f@cjnash.com>
 <f8a23e32-e1df-4f48-928b-3d05fa2850b3@oracle.com>
Message-ID: <d64d2551-07d0-de02-5512-1f4aea8c1c72@cjnash.com>

Yes, definitely OK on JDK 21.0.1 and not OK on JDK 22 b16.

Simon

On 25/11/2023 22:57, Philip Race wrote:
> I'm stumped then. Definitely not a problem with JDK 21u1 ?
> https://download.java.net/java/GA/jdk21.0.1/415e3f918a1f4062a0074a2794853d0d/12/GPL/openjdk-21.0.1_windows-x64_bin.zip
>
> Try some earlier JDK 22 build too - looks like b16 is the earliest that is available for download
> https://download.java.net/java/early_access/jdk22/16/GPL/openjdk-22-ea+16_windows-x64_bin.zip
>
> -phil.
>
> On 11/25/23 1:46 PM, Simon Nash wrote:
>> I tried this with JDK 22 b22 and I got the same result. I will investigate further.
>>
>> Simon
>>
>> On 25/11/2023 18:33, Philip Race wrote:
>>> Re-read the last line of my previous email and you'll see the answer.
>>>
>>> -phil.
>>>
>>> On 11/25/23 2:09 AM, Simon Nash wrote:
>>>> Thanks for confirming that this change was not intentional. I am using the JDK 22 b24 EA build. When was the Windows compiler and SDK updated?
>>>>
>>>> Simon
>>>>
>>>> On 24/11/2023 23:30, Philip Race wrote:
>>>>> I don't recall anything specific to this. Since you say "current EA build", does that imply very recently ?
>>>>> My guess is that it is fall out from upgrading the Windows compiler + SDK and
>>>>> we are no longer able to load the uxtheme library on Windows 7 needed for the WindowsL&F.
>>>>> Note that it has been several years since anyone supported or tested Windows 7.
>>>>> If you can confirm this started with JDK 22 b23 that would pretty much confirm the theory.
>>>>>
>>>>> -phil.
>>>>>
>>>>> On 11/24/23 3:08 PM, Simon Nash wrote:
>>>>>> In the current EA build of JDK 22, selecting WindowsLookAndFeel on Windows 7 shows the same (ugly) UI style as WindowsClassicLookAndFeel.
>>>>>>
>>>>>> With JDK 22 on Windows 10 and also with JDK 21 and below on both Windows 7 and Windows 10, this works as expected with different styles for 
>>>>>> WindowsLookAndFeel and WindowsClassicLookAndFeel.
>>>>>>
>>>>>> Is this an intentional change in JDK 22 or a bug? If it is intentional, what was the reason?
>>>>>>
>>>>>> Thanks, Simon
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231127/4ae8df93/attachment-0001.htm>

From prr at openjdk.org  Mon Nov 27 19:29:20 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Nov 2023 19:29:20 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
Message-ID: <jBqUQxZE78tdoPFlZy8uhjpen-y_JxMi2RLoPlTNhCk=.f30a3a7a-91b2-4479-a788-e050f412b2cf@github.com>

On Thu, 23 Nov 2023 11:10:35 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> test/jdk/java/awt/PrintJob/EdgeTest/EdgeTest.java line 30:
> 
>> 28:  * @summary Verifies that (0, 0) is the upper-left corner of the page, not
>> 29:  *          the upper-left corner adjusted for the margins.
>> 30:  * @author dpm
> 
> Suggestion:
> 
> 
> Perhaps, remove the `@author` tag here too.

will do, although removing author tags was just something I was doing as I went along and happened to spot them ..

> test/jdk/java/awt/PrintJob/RoundedRectTest/RoundedRectTest.java line 29:
> 
>> 27:  * @bug 4061440
>> 28:  * @summary Checks that rounded rectangles print correctly.
>> 29:  * @author dpm
> 
> Suggestion:

will do

> test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 30:
> 
>> 28: 
>> 29: import java.awt.*;
>> 30: import java.awt.print.*;
> 
> Could you expand the wildcard imports, please?
> 
> I would appreciate if you would add the jtreg tags *after* the imports.

I can .. but I am not aware of even a convention to do that ordering.
I'll update the imports in this file since I touched it more than any other case

> test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 35:
> 
>> 33: {
>> 34:    public static void main(String args[])
>> 35:    {
> 
> Suggestion:
> 
> public class SmallPaperPrinting {
>    public static void main(String[] args) {
> 
> Since you're reformatting the test source, it's better to follow the Java code style? throughout the entire source file.

ok.

> test/jdk/java/awt/print/PageFormat/WrongPaperPrintingTest.java line 29:
> 
>> 27:    @key printer
>> 28:    @run main/manual WrongPaperPrintingTest
>> 29:  */
> 
> It's minor but still, in majority of tests, the `@key` tag follows the `@bug` tag, and you mostly follow the convention in this PR. Keeping the order consistent helps scanning the test description with eyes quickly.

updated

> test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 30:
> 
>> 28:  * @key printer
>> 29:  * @run main EmptyFill
>> 30:  */
> 
> This test does not need a printer, it prints into a byte array and analyses the output. The test passes successfully on a system without a printer.

You are right, I mis-read this
       PrinterJob pj = PrinterJob.getPrinterJob();
       if (svc == null) {
           return;
       }
that test bails if there's no service but that's if it failed to create the output stream service
Not sure why the code is ordered that way round since we can check for null first.

> test/jdk/java/awt/print/PrinterJob/GetUserNameTest.java line 26:
> 
>> 24:  * @test
>> 25:  * @bug 6197099
>> 26:  * @key printer
> 
> The test works correctly without a printer, it prints the expected message:
> 
> SecurityException thrown as user.name permission not given
> 
> 
> No other exceptions are thrown but the warnings that `SecurityManager` is deprecated.

fixed

> test/jdk/java/awt/print/PrinterJob/MultiMonPrintDlgTest.java line 40:
> 
>> 38:  * @test
>> 39:  * @bug 8138749
>> 40:  * @key printer
> 
> Suggestion:
> 
>  * @key printer multimon
> 
> The test requires two monitors.

fixed. I meant to add this but forgot.

> test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 26:
> 
>> 24: /**
>> 25:  *
>> 26:  * @bug 4884389 7183516
> 
> Is it intentional that there's no `@test` tag?

I think this is another test that needs some work. It doesn't wait to see if the user gave it a pass.
I'll add "test" but not "@test".

> test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 29:
> 
>> 27:  * @key printer
>> 28:  * @summary Font specified with face name loses style on printing
>> 29:  * @run main/manual PrintRotatedText
> 
> Is it intentional that this test presumably runs another test ? `PrintRotatedText` ? instead?

that looks wrong. will fix

> test/jdk/java/awt/print/PrinterJob/PrintTranslatedFont.java line 29:
> 
>> 27:  * @key printer
>> 28:  * @summary Test that fonts with a translation print where they should.
>> 29:  * @author prr
> 
> Suggestion:

fixed

> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 31:
> 
>> 29:  * @key printer
>> 30:  * @run main/othervm PrinterDevice
>> 31:  */
> 
> There's no `@test` tag, is it intentional?
> 
> Probably, you should remove this test from this PR because you're modifying in #16773.

agreed

> test/jdk/java/awt/print/PrinterJob/PrinterDialogsModalityTest/PrinterDialogsModalityTest.html line 30:
> 
>> 28:   @key printer
>> 29:   @summary check whether Print- and Page- dialogs are modal and correct window activated after their closing
>> 30:   @author Your Name: area=PrinterJob.modality
> 
> Suggestion:

fixed

> test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 25:
> 
>> 23: 
>> 24: /*
>> 25:  * @test 1.1 01/05/17
> 
> Suggestion:
> 
>  * @test

fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406595049
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406595720
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406610431
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406621800
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406627499
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406630862
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406631860
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406633247
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406639812
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406638321
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406640707
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406642687
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406643230
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406643654

From prr at openjdk.org  Mon Nov 27 19:29:06 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Nov 2023 19:29:06 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <-qqvX2JKzr3-eQ_FNsovChX5aJjqQaqbewiVgvCamM0=.644272b2-55b3-4d32-8e57-7de1f9ec5590@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-qqvX2JKzr3-eQ_FNsovChX5aJjqQaqbewiVgvCamM0=.644272b2-55b3-4d32-8e57-7de1f9ec5590@github.com>
Message-ID: <C9IwnKW2BuFF30fWLVPexbZnyA4hjbYSNoNKaziUKwQ=.43033028-74c9-4cd0-b299-76926d9820f8@github.com>

On Thu, 23 Nov 2023 07:02:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> test/jdk/TEST.ROOT line 15:
> 
>> 13: #
>> 14: # Notes on "client" keywords : headful sound printer 2d dnd multimon 
>> 15: # ==================================================================
> 
> The note reads well but there aren't any notes for "2d" and "dnd". The heading hints that there will be information on these keywords.

That's because I wasn't sure what we use them for :-)
I've grepped and they are never used.
I'm not sure we need either of them so I think I'll just remove them.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406590062

From prr at openjdk.org  Mon Nov 27 19:29:23 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Nov 2023 19:29:23 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword
In-Reply-To: <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
 <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com>
Message-ID: <zOg35G9S05wsck3K-Ps2-g0wcFUQS8KekSmCjBY9oTE=.266b65ca-cb70-4cf6-be32-48ca332ef886@github.com>

On Thu, 23 Nov 2023 20:39:50 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/java/awt/print/PageFormat/SetOrient.java line 28:
>> 
>>> 26:  * @summary Confirm that the clip and transform of the Graphics2D is
>>> 27:  *          affected by the landscape orientation of the PageFormat.
>>> 28:  */
>> 
>> Since this test calls `pjob.print();`, it requires a printer. Indeed, it fails without a printer:
>> 
>> 
>> runner starting test: java/awt/print/PageFormat/SetOrient.html
>> runner finished test: java/awt/print/PageFormat/SetOrient.html
>> Failed. Execution failed: Applet thread threw exception:
>>         java.lang.RuntimeException: No print service found.
>> Test results: failed: 1
>
> I see `SetOrient.java` has its sibling `SetOrient.html` where you added `@key printer`.
> 
> Since both files contain all the tags except for `@test` in the .java file, you should not remove the `@run` tag from the .java file and add `@key printer` to it.

"Should not" is strong. Why ? There's no requirement do to this even though you can.
https://openjdk.org/jtreg/faq.html#can-i-use-the-author-run-etc.-tags-in-other-files

>> test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 42:
>> 
>>> 40:      System.out.println("A passing test should catch a PrinterException");
>>> 41:      System.out.println("and should display \"Print error: (exception msg)\".");
>>> 42:      System.out.println("---------------------------------------------------\n");
>> 
>> According to these instructions, the test is to contain a set of `@test` tags:
>> 
>> 
>> /*
>> * @test
>> * @key printer
>> * @run main/othervm SmallPaperPrinting
>> */
>> 
>> /*
>>  * @test
>>  * @key printer
>>  * @run main/othervm SmallPaperPrinting 1
>>  */
>> 
>> /*
>>  * @test
>>  * @key printer
>>  * @run main/othervm SmallPaperPrinting 2
>>  */
>> 
>> 
>> Otherwise, it won't run all the cases and no one will ever see these instructions.
>> 
>> For me, the test with the added `@test` tags as above prints an error message in the first two cases:
>> 
>> # id0.jtr
>> Print error:
>> Paper's imageable height is too small.
>> # id1.jtr
>> Print error:
>> Paper's imageable width is too small.
>> 
>> 
>> Yet it does not print any error message in the third case where `width=-1`, and **it does not fail**.
>> 
>> If I run it on a system without a printer, the test also *passes successfully*. Perhaps, we can ignore it as the `@key printer` ensures there's a printer the system.
>> 
>> Having said the above, this test requires its own bug to fix the test.
>
>> Having said the above, this test requires its own bug to fix the test.
> 
> I submitted [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671): PageFormat/SmallPaperPrinting.java needs three sets of @test tags

I saw that, and it didn't fail at all on mac for any case.
Not sure how much I want to get dragged into fixing the test, and there's no bug id to refer back to.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406605795
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1406627015

From prr at openjdk.org  Mon Nov 27 20:20:38 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 27 Nov 2023 20:20:38 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
Message-ID: <YK2EQtIP0-86eeLa1lOndwrMzuQ3uEh1VSIzmag1QrM=.21a33860-a201-48de-8be6-2b4c31fc5aa4@github.com>

> Many printing tests do not have the @printer keyword. This adds them to those that need it.
> I also found one test that has nothing to do with printing in the print folder and moved it out.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8320608

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16785/files
  - new: https://git.openjdk.org/jdk/pull/16785/files/cea88f00..5fbc06d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=00-01

  Stats: 52 lines in 13 files changed: 16 ins; 13 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/16785.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16785/head:pull/16785

PR: https://git.openjdk.org/jdk/pull/16785

From anthony.goubard at gmail.com  Mon Nov 27 20:21:08 2023
From: anthony.goubard at gmail.com (Anthony Goubard)
Date: Mon, 27 Nov 2023 21:21:08 +0100
Subject: Unneeded array assignments in client-libs
Message-ID: <CANsEkGtsPBDMVuLspb5M1bOvLAm1zPyHr+usMia2A8Fc1JPU_g@mail.gmail.com>

Hello,

 Last Friday, I decided to look if there were some classes that did
unneeded array assignments (e.g. to 0 / 0.0f / null / false) in the JDK and
found many in the client-libs.

 Here are a few examples of unneeded assignments done in a for loop:
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L344
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L359
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java#L1423
https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1180
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/media/sound/SoftLanczosResampler.java#L61
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/rtf/AbstractFilter.java#L69
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java#L579
https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java#L913
-> move to the else branch

Note that I listed here some of them found in the client-libs but I also
found others in other parts of OpenJDK.

I think you may be interested in removing these unneeded assignments. If
so, can you let me know how you would like to proceed?

 * My idea would be that I create an issue in JBS per classes/category
along with a merge request from my github repository. I would need Author
access for this.
 * I can also send the list to the different mailing lists.
 * Or if you prefer, I can create one issue per part of the JDK with a
merge request.

I also found a few that were not in a for loop, let me know if you're also
interested to know about these ones.

Best regards,
Anthony Goubard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231127/98a67d11/attachment.htm>

From philip.race at oracle.com  Mon Nov 27 20:31:19 2023
From: philip.race at oracle.com (Philip Race)
Date: Mon, 27 Nov 2023 12:31:19 -0800
Subject: Unneeded array assignments in client-libs
In-Reply-To: <CANsEkGtsPBDMVuLspb5M1bOvLAm1zPyHr+usMia2A8Fc1JPU_g@mail.gmail.com>
References: <CANsEkGtsPBDMVuLspb5M1bOvLAm1zPyHr+usMia2A8Fc1JPU_g@mail.gmail.com>
Message-ID: <36ddaa90-6b88-408e-8b1b-ddf47c342008@oracle.com>

I think almost all of these add sufficient extra clarity and have no 
performance impact that matters,
so I would leave them all alone.

-phil.

On 11/27/23 12:21 PM, Anthony Goubard wrote:
> Hello,
>
> ?Last Friday, I decided to look if there were some classes that did 
> unneeded array assignments (e.g. to 0 / 0.0f / null / false) in the 
> JDK and found many in the client-libs.
>
> ?Here are a few examples of unneeded assignments done in a for loop:
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L344
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/sun/java2d/cmm/lcms/LCMSTransform.java#L359
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/imageio/plugins/jpeg/JPEGImageWriter.java#L1423
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsFileChooserUI.java#L1180
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/media/sound/SoftLanczosResampler.java#L61
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/text/rtf/AbstractFilter.java#L69
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/tree/DefaultTreeSelectionModel.java#L579
> https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/com/sun/imageio/plugins/bmp/BMPImageWriter.java#L913 
> -> move to the else branch
>
> Note that I listed here some of them found in the client-libs but I 
> also found others in other parts of OpenJDK.
>
> I think you may be interested in removing these unneeded assignments. 
> If so, can you let me know how you would like to proceed?
>
> ?* My idea would be that I create an issue in JBS per classes/category 
> along with a merge request from my github repository. I would need 
> Author access for this.
> ?* I can also send the list to the different mailing lists.
> ?* Or if you prefer, I can create one issue per part of the JDK with a 
> merge request.
>
> I also found a few that were not in a for loop, let me know if you're 
> also interested to know about these ones.
>
> Best regards,
> Anthony Goubard


From vtsty.dev at gmail.com  Thu Nov 23 05:30:54 2023
From: vtsty.dev at gmail.com (V S)
Date: Thu, 23 Nov 2023 07:30:54 +0200
Subject: sun.print.RasterPrinterJob change request
Message-ID: <CA+MPai9JWe8CJCKq1vpYoXCC7hDmvSrxzndMqJLZvW01wM0wYQ@mail.gmail.com>

Hello Everybody
I think there is a bug in sun.print.RasterPrinterJob, namely in
banded-raster printing loop of
"printPage" method.
The way to reproduce this bug is described here
https://stackoverflow.com/questions/76110553/java-print-api-renders-on-paper-skewed-graphics
this bug is seen only when real printer device is set as default (not PDF
printer !!!!!!). Device must have nonzero PHYSICALOFFSETX and
PHYSICALOFFSETY devicecaps.
I would like to propose bug-fix. What I have to do  ?

Best Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231123/8ddf1bb9/attachment.htm>

From philip.race at oracle.com  Mon Nov 27 20:37:39 2023
From: philip.race at oracle.com (Philip Race)
Date: Mon, 27 Nov 2023 12:37:39 -0800
Subject: sun.print.RasterPrinterJob change request
In-Reply-To: <CA+MPai9JWe8CJCKq1vpYoXCC7hDmvSrxzndMqJLZvW01wM0wYQ@mail.gmail.com>
References: <CA+MPai9JWe8CJCKq1vpYoXCC7hDmvSrxzndMqJLZvW01wM0wYQ@mail.gmail.com>
Message-ID: <d7515ea6-d550-4aec-86b9-5a34c0284864@oracle.com>

If you want to submit a bug report on this go to 
https://bugreport.java.com/bugreport/

If you want to propose a patch you'll need to
1) very carefully read https://openjdk.org/contribute/
2) follow the steps to become a contributor.
3) Learn the client-area code and testing expectations discussed here 
https://openjdk.org/groups/client-libs/
4) find a sponsor
5) propose the tested patch.

Also you need to subscribe to this list to post to it.

-phil

On 11/22/23 9:30 PM, V S wrote:
> Hello Everybody
> I think there is a bug in sun.print.RasterPrinterJob, namely in 
> banded-raster printing loop of
> "printPage" method.
> The way to reproduce this bug is described here 
> https://stackoverflow.com/questions/76110553/java-print-api-renders-on-paper-skewed-graphics
> this bug is seen only when real printer device is set as default (not 
> PDF printer !!!!!!). Device must have nonzero PHYSICALOFFSETX and 
> PHYSICALOFFSETY devicecaps.
> I would like to propose bug-fix. What I have to do? ?
>
> Best Regards


From tr at openjdk.org  Tue Nov 28 08:34:46 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 28 Nov 2023 08:34:46 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v8]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/188a7c9d..15de3608

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=06-07

  Stats: 60 lines in 2 files changed: 14 ins; 10 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/16374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16374/head:pull/16374

PR: https://git.openjdk.org/jdk/pull/16374

From tr at openjdk.org  Tue Nov 28 08:34:47 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 28 Nov 2023 08:34:47 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v3]
In-Reply-To: <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <qKXFmoAET2B_ENM7Lpotei9LkgRAb2RjlK95ht5Cjp8=.c622ecfe-2118-4cef-9f13-e7e624a5beaf@github.com>
 <9yVJmBv_HLW9Rn-gljheM3IluA3GMNID-F_pHpWz7pk=.4e70c8c6-d2b6-48d2-8a49-36634f9f0402@github.com>
Message-ID: <5Nswyr-23pkomM74qbi_QehGxfn0T7ELWnBHZLEH5p4=.6729fb25-8700-4748-91c1-eb130c3c1a52@github.com>

On Wed, 8 Nov 2023 08:49:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
>> similar to how header is painted
> 
> Can you please point to the code where the header is painted similarly?

@prsadhuk @aivanov-jdk Can u please let me know if any review suggestions are there for this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16374#issuecomment-1829331928

From psadhukhan at openjdk.org  Tue Nov 28 12:10:07 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 28 Nov 2023 12:10:07 GMT
Subject: RFR: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
Message-ID: <8YSd_JrGbOBBbWhsU2yriDD3aO0R9JKmtiQnNk5KL3I=.f61f064d-f7ef-4e0a-b7bc-6c8f8b4e0ef8@github.com>

On Thu, 12 Oct 2023 15:51:28 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
> The same is true for `CustomMediaTray` class.
> 
> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
> 
> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.

Marked as reviewed by psadhukhan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16167#pullrequestreview-1752727535

From ihse at openjdk.org  Tue Nov 28 17:07:20 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 28 Nov 2023 17:07:20 GMT
Subject: RFR: 8320915: Update copyright year in build files
Message-ID: <-4RrV3-LPfsh3BT-qwj3WtF1szg-_6Tt3RxnysPpNeo=.f2b0fee1-7d0c-4c43-bc4f-39ad9fec1150@github.com>

Over the year, even though we have tried to be diligent, there have been commits that modify files without updating the copyright year. Here is a mass update of the copyright years in the build system (`make/**`, `.github/**`). 

Feel free to verify that these files have indeed been modified in 2023 :-), or trust my tools + manual verification. Also, as far as I (and my tools) can tell, this is the only files modified in 2023 that have not had their header updated.

-------------

Commit messages:
 - 8320915: Update copyright year in build files

Changes: https://git.openjdk.org/jdk/pull/16858/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16858&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8320915
  Stats: 69 lines in 69 files changed: 0 ins; 0 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/16858.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16858/head:pull/16858

PR: https://git.openjdk.org/jdk/pull/16858

From honkar at openjdk.org  Tue Nov 28 17:42:24 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 28 Nov 2023 17:42:24 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v3]
In-Reply-To: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
Message-ID: <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> 
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  static vars and null checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16569/files
  - new: https://git.openjdk.org/jdk/pull/16569/files/5493f5f9..4b57f781

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16569&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16569&range=01-02

  Stats: 31 lines in 2 files changed: 16 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/16569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16569/head:pull/16569

PR: https://git.openjdk.org/jdk/pull/16569

From achung at openjdk.org  Tue Nov 28 17:46:19 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 28 Nov 2023 17:46:19 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode
 on different keyboard layouts [v2]
In-Reply-To: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
Message-ID: <6rYOTBqZdRNi3o9m2O3S9rdslhDg-lgBLkUs4Yne1p8=.3ad46b75-7ef1-47a9-b8a2-98d4314dde20@github.com>

> Updated previous fix (8262945) to work on extendedKeyCodes. Updated AcceleratorTest to use PassFailJFrame instead of Applet

Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:

  updated test to provide information on which key was pressed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16664/files
  - new: https://git.openjdk.org/jdk/pull/16664/files/00e6daef..f52f4b11

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16664&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16664&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16664.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16664/head:pull/16664

PR: https://git.openjdk.org/jdk/pull/16664

From achung at openjdk.org  Tue Nov 28 17:46:21 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 28 Nov 2023 17:46:21 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode
 on different keyboard layouts [v2]
In-Reply-To: <kSSGyw3_Dyx3zcceRFIQ1ekh_6xC5m0Z8hZfoglgPy0=.4ebba018-b261-44ef-becb-e2c216dd9cba@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
 <kSSGyw3_Dyx3zcceRFIQ1ekh_6xC5m0Z8hZfoglgPy0=.4ebba018-b261-44ef-becb-e2c216dd9cba@github.com>
Message-ID: <3SkNsS6XmXuD294FMtPV0DbiitW1NP7Ks7i8gPPFfoc=.b3e9490a-43a7-4dcd-838c-dd83f586304c@github.com>

On Thu, 16 Nov 2023 18:24:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated test to provide information on which key was pressed
>
> test/jdk/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java line 1:
> 
>> 1: /*
> 
> Is it possible to print which particular event fired? It could be useful for debugging.
> 
> I'd create a list of `Action`s with the names and shortcuts (as a KeyStroke and as string for printing) and then print each action name with corresponding shortcut. Or create a list of objects with corresponding data. I didn't think it through.

I've just updated the test to print the ActionEvent's getActionCommand, so there is information on which key was pressed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16664#discussion_r1408149928

From honkar at openjdk.org  Tue Nov 28 17:47:13 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 28 Nov 2023 17:47:13 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v3]
In-Reply-To: <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
Message-ID: <KkJenZ6SMb-TJadFhSglP5Yo7GPFU6CBNadLFs0wDMQ=.c4dbc88e-44cf-4c09-95f4-8e6771381e2f@github.com>

On Tue, 28 Nov 2023 17:42:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in the unforeseen case where it could be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> 
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static vars and null checks

The latest update has the following changes -

- Static variables used to read the env var values only once as suggested here [16569#discussion](https://github.com/openjdk/jdk/pull/16569#discussion_r1394683107)

- sharedDelegate null checks added in AppDelegate.m (JNI call locations), tested using Embedded JFX, SWT examples where sharedDelegate is null. In case of Embedded SWT, SWT creates SWTApplication (a subclass of NSApp) similar to the new JFX changes.

- As described earlier, these null checks are essential and prudent to bail out early and not rely on Objective-C nil behavior. [16569#discussion](https://github.com/openjdk/jdk/pull/16569#discussion_r1399604866)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16569#issuecomment-1830374897

From prr at openjdk.org  Tue Nov 28 18:12:14 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 28 Nov 2023 18:12:14 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v3]
In-Reply-To: <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
Message-ID: <-IDNcFFqU9Jr6xaPNCkdxkGb9H5jI5v3_BzFfJBvFdw=.82a0a6f3-d9b0-487e-bdbc-f7c82af5ba77@github.com>

On Tue, 28 Nov 2023 17:42:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in cases where it can be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> Test scenarios involving JDK and JFX fixes is documented here 
>> [Updated_Test_Scenarios.xlsx](https://github.com/openjdk/jdk/files/13491545/Updated_Test_Scenarios.xlsx)
>> 
>>  
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static vars and null checks

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16569#pullrequestreview-1753569130

From kizune at openjdk.org  Tue Nov 28 18:40:09 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 28 Nov 2023 18:40:09 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v3]
In-Reply-To: <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
Message-ID: <otfplwhINyRDjPopMm3NsJ4vJiXyySi0Hb5VH9sQpMY=.0c57b3f6-b771-4dc4-a9b5-6f3657a823d7@github.com>

On Tue, 28 Nov 2023 17:42:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in cases where it can be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> Test scenarios involving JDK and JFX fixes is documented here 
>> [Updated_Test_Scenarios.xlsx](https://github.com/openjdk/jdk/files/13491545/Updated_Test_Scenarios.xlsx)
>> 
>>  
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static vars and null checks

Marked as reviewed by kizune (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16569#pullrequestreview-1753636468

From shurailine at openjdk.org  Tue Nov 28 19:36:08 2023
From: shurailine at openjdk.org (Alexandre Iline)
Date: Tue, 28 Nov 2023 19:36:08 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v6]
In-Reply-To: <8pVL-HXwf1kF_TQ3NxX5O0qwoxW9OahYK9sXwMGYZqc=.b1cb415c-500d-4939-b94d-2808a7847649@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <FyVlQDMdF7tji0yw8dEUI9VMRaqayYv0qhvmth_VywQ=.09f4d384-5deb-4c73-82df-7288707d28d2@github.com>
 <8pVL-HXwf1kF_TQ3NxX5O0qwoxW9OahYK9sXwMGYZqc=.b1cb415c-500d-4939-b94d-2808a7847649@github.com>
Message-ID: <zt22hWY8tUxfEtKD_bcXr5J2a4YByxfks6iQi9p6dFY=.3be511e7-e243-4945-a7b3-bce078e55b3d@github.com>

On Tue, 21 Nov 2023 08:37:00 GMT, songpv-imt <duke at openjdk.org> wrote:

> Hmm... Are you suggesting instead of using SYNC_LOCK, for better code transparency, we should place the code that accesses the listener's fields from the main thread into AWT Event Queue with EventQueue.invokeAndWait? Can you please check if the update code meets your suggestion? Thanks.

Yes. Half of the access to the state of the listener is already on the even queue. It would be pretty transparent to make the other part of the access to go through the queue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1830542554

From achung at openjdk.org  Tue Nov 28 22:40:21 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 28 Nov 2023 22:40:21 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on the
 outside area didn't cause ungrab
Message-ID: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>

Added delays to stabilize test, test passes 50 times consecutively

-------------

Commit messages:
 - added delays to stabilize test

Changes: https://git.openjdk.org/jdk/pull/16867/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16867&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317288
  Stats: 56 lines in 1 file changed: 34 ins; 6 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16867.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16867/head:pull/16867

PR: https://git.openjdk.org/jdk/pull/16867

From dnguyen at openjdk.org  Tue Nov 28 23:47:13 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 28 Nov 2023 23:47:13 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text
Message-ID: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>

The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.

This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning. In addition, a new line is added to BasicLookAndFeel (since Metal derives its default button margin here) to better document the difference in button margins compared to other L&Fs.

-------------

Commit messages:
 - Initial fix. Revert changes and update doc instead.

Changes: https://git.openjdk.org/jdk/pull/16869/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16869&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318590
  Stats: 195 lines in 5 files changed: 11 ins; 177 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16869.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16869/head:pull/16869

PR: https://git.openjdk.org/jdk/pull/16869

From serb at openjdk.org  Wed Nov 29 06:55:09 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Nov 2023 06:55:09 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <GYl77levqVWWjHspziWqYk4F9ZT1KI_dE4pURDcwjeo=.935c7d09-ad4c-4cc3-aba8-49db69ac9fdd@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
 <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
 <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>
 <GYl77levqVWWjHspziWqYk4F9ZT1KI_dE4pURDcwjeo=.935c7d09-ad4c-4cc3-aba8-49db69ac9fdd@github.com>
Message-ID: <Jvz7UsJV11B3q9eAFquhXVbnalK_KZyiX5wWJSmKnvA=.fe3a1a6f-4fec-4cdc-8713-9036669c60c9@github.com>

On Mon, 20 Nov 2023 23:51:09 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @prrace @kevinrushforth @mrserb 
>> 
>> The reason has to why we don't observe NPE or crash when sharedDelegate is null is because in Objective C when a method is called on a nil object it is treated as no-op and returns nil instead of NPE, contrary to what we would usually expect. Details [here](https://stackoverflow.com/questions/2696891/calling-a-method-on-an-uninitialized-object-null-pointer).
>> 
>> For example executing the following line when shared delegate is null and accessing defaultMenuBar on null delegate returns null and not NPE.
>> 
>> `[[ApplicationDelegate sharedDelegate] defaultMenuBar];`
>> 
>> Additionally we are not seeing any difference with defaultMenuBar case with unpatched JDK + unpatched JFX (Non-Nil shared delegate) vs patched JDK + patched JFX (Nil shared delegate) at [AWTWindow.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/AWTWindow.m#L844) and [CMenubar.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/CMenuBar.m#L213)  because in both cases defaultMenuBar returned is nil. This might be the case at other places too and are being checked if they worked differently without and with this JDK patch.
>
> So in  either case -- with or without the delegate being overridden -- the defaultMenuBar is returning `nil`. This makes sense, since in the case of a JavaFX app, JavaFX has already initialized the `NSApplication` and set the system menu bar.
> 
> I do recommend leaving the `sharedDelegate` null checks that you added as part of this PR, since that way we short-circuit any other logic (e.g., in this specific case you avoid setting `isDisabled = NO` which seems more accurate), and you aren't relying on Objective C to treat this case as a no-op.
> 
> You might even consider making the `sharedDelegate` null check (and bailing out) earlier, but maybe there is a good reason to leave the check where it is.

>The reason has to why we don't observe NPE or crash when sharedDelegate is null is

But why it is null? The OSXAPP_SetApplicationDelegate is called when the LWCToolkit is initialized in non-headless [mode](https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m#L355) and that code does not depend on "NSApplicationAWT". Does it mean that the toolkit is not initiated? Then how we can call peer-menu-related code? if that code path is not executed probably we should change that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1408823737

From serb at openjdk.org  Wed Nov 29 06:58:06 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Nov 2023 06:58:06 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <Jvz7UsJV11B3q9eAFquhXVbnalK_KZyiX5wWJSmKnvA=.fe3a1a6f-4fec-4cdc-8713-9036669c60c9@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
 <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
 <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>
 <GYl77levqVWWjHspziWqYk4F9ZT1KI_dE4pURDcwjeo=.935c7d09-ad4c-4cc3-aba8-49db69ac9fdd@github.com>
 <Jvz7UsJV11B3q9eAFquhXVbnalK_KZyiX5wWJSmKnvA=.fe3a1a6f-4fec-4cdc-8713-9036669c60c9@github.com>
Message-ID: <NNxHlMySTPT52pVJ5bymGz4ayCTZefaaacySkqL18so=.4c214ac7-71d9-46d3-8489-050143bba743@github.com>

On Wed, 29 Nov 2023 06:51:27 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> So in  either case -- with or without the delegate being overridden -- the defaultMenuBar is returning `nil`. This makes sense, since in the case of a JavaFX app, JavaFX has already initialized the `NSApplication` and set the system menu bar.
>> 
>> I do recommend leaving the `sharedDelegate` null checks that you added as part of this PR, since that way we short-circuit any other logic (e.g., in this specific case you avoid setting `isDisabled = NO` which seems more accurate), and you aren't relying on Objective C to treat this case as a no-op.
>> 
>> You might even consider making the `sharedDelegate` null check (and bailing out) earlier, but maybe there is a good reason to leave the check where it is.
>
>>The reason has to why we don't observe NPE or crash when sharedDelegate is null is
> 
> But why it is null? The OSXAPP_SetApplicationDelegate is called when the LWCToolkit is initialized in non-headless [mode](https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m#L355) and that code does not depend on "NSApplicationAWT". Does it mean that the toolkit is not initiated? Then how we can call peer-menu-related code? if that code path is not executed probably we should change that?

I found a reason in one comment above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1408826874

From serb at openjdk.org  Wed Nov 29 07:17:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 29 Nov 2023 07:17:08 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <NNxHlMySTPT52pVJ5bymGz4ayCTZefaaacySkqL18so=.4c214ac7-71d9-46d3-8489-050143bba743@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
 <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
 <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>
 <GYl77levqVWWjHspziWqYk4F9ZT1KI_dE4pURDcwjeo=.935c7d09-ad4c-4cc3-aba8-49db69ac9fdd@github.com>
 <Jvz7UsJV11B3q9eAFquhXVbnalK_KZyiX5wWJSmKnvA=.fe3a1a6f-4fec-4cdc-8713-9036669c60c9@github.com>
 <NNxHlMySTPT52pVJ5bymGz4ayCTZefaaacy
 SkqL18so=.4c214ac7-71d9-46d3-8489-050143bba743@github.com>
Message-ID: <r9veZ2oSoZVgmSqMff238EIEiCLWw-Uh5b0-vFhXj-M=.068b8110-c88b-4692-9912-46eea56f710e@github.com>

On Wed, 29 Nov 2023 06:55:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>>>The reason has to why we don't observe NPE or crash when sharedDelegate is null is
>> 
>> But why it is null? The OSXAPP_SetApplicationDelegate is called when the LWCToolkit is initialized in non-headless [mode](https://github.com/openjdk/jdk/blob/9a6ca233c7e91ffa2ce9451568b3be88ccd04504/src/java.desktop/macosx/native/libawt_lwawt/awt/LWCToolkit.m#L355) and that code does not depend on "NSApplicationAWT". Does it mean that the toolkit is not initiated? Then how we can call peer-menu-related code? if that code path is not executed probably we should change that?
>
> I found a reason in one comment above.

I guess the code [ApplicationDelegate.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m#L118C4-L128C33) should be changed. Right now it has some checks to prevent "double initialization", but it should take care about the case if the delegate is set already by some external lib. 
Leaving that as null and skip it in the code means that part of the API will stop working, mostly java.awt.desktop package?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1408843056

From vtsty.dev at gmail.com  Wed Nov 29 09:58:51 2023
From: vtsty.dev at gmail.com (V S)
Date: Wed, 29 Nov 2023 11:58:51 +0200
Subject: bug in RasterPrinterJob
Message-ID: <CA+MPai8fycc30ZrfYXCVuK7_XziFQvkhdyYogP7RF+6oes4CSw@mail.gmail.com>

Hello everybody
I think there is a bug in sun.print.RasterPrinterJob, namely in
banded-raster printing loop of
"printPage" method. This bug occurs on Windows platform only, when real
printer prints on real paper and getPhysicalPrintableX,
getPhysicalPrintableY methods of sun.awt.windows.WPrinterJob return
non-zero values. JDK version doesn't matter.
How to reproduce it is described here
https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8307246
https://stackoverflow.com/questions/76110553/java-print-api-renders-on-paper-skewed-graphics
I would like to propose a bug fix.
May anybody reproduce this bug either to confirm that there is the bug or
to disprove it?
May anybody be a sponsor if a bug is confirmed ?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231129/f7f2f375/attachment.htm>

From prasanta.sadhukhan at oracle.com  Wed Nov 29 10:19:23 2023
From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan)
Date: Wed, 29 Nov 2023 15:49:23 +0530
Subject: bug in RasterPrinterJob
In-Reply-To: <CA+MPai8fycc30ZrfYXCVuK7_XziFQvkhdyYogP7RF+6oes4CSw@mail.gmail.com>
References: <CA+MPai8fycc30ZrfYXCVuK7_XziFQvkhdyYogP7RF+6oes4CSw@mail.gmail.com>
Message-ID: <285c62a4-1ee2-4dd4-bb3d-5d1c70e91a7f@oracle.com>

It seems there is a bug which I did reproduce and if a github fix PR is 
raised, I can sponsor it when approved by reviewers.

Regards
Prasanta
On 29-Nov-23 3:28 PM, V S wrote:
> Hello everybody
> I think there is a bug in sun.print.RasterPrinterJob, namely in 
> banded-raster printing loop of
> "printPage" method. This bug occurs on Windows platform only, when 
> real printer prints on real paper and getPhysicalPrintableX, 
> getPhysicalPrintableY methods of sun.awt.windows.WPrinterJob return 
> non-zero values. JDK version doesn't matter.
> How to reproduce it is described here
> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8307246
> https://stackoverflow.com/questions/76110553/java-print-api-renders-on-paper-skewed-graphics
> I would like to propose a bug fix.
> May anybody reproduce this bug either to confirm that there is the bug 
> or to disprove it?
> May anybody be a sponsor if a bug is confirmed ?
> Thanks

From psadhukhan at openjdk.org  Wed Nov 29 10:26:16 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 29 Nov 2023 10:26:16 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v8]
In-Reply-To: <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>
Message-ID: <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>

On Tue, 28 Nov 2023 08:34:46 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2033:

> 2031:             for (int row = rMin; row <= rMax; row++) {
> 2032:                 y += table.getRowHeight(row);
> 2033:                 SwingUtilities2.drawHLine(g, damagedArea.x, damagedArea.x + tableWidth - 1, y - 1);

Is this needed? seems like it's working even without this change..

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 582:

> 580:         TableColumn aColumn;
> 581:         int columnWidth;
> 582:         boolean ltrFlag = table.getComponentOrientation().isLeftToRight();

Is SynthTableUI change needed? Seems like your test is passing for Nimbus L&F even without this file change

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 103:

> 101:                                 saveImage(bufferedImage, "failureImage.png");
> 102:                                 failureString = "Test Failed at <" + x + ", " + y + ">";
> 103:                                 break;

This ideally should be done outside EDT..

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1408974181
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1408975271
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1409070332

From tr at openjdk.org  Wed Nov 29 13:21:19 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 29 Nov 2023 13:21:19 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v8]
In-Reply-To: <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>
 <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>
Message-ID: <bEPnFCyMAp2x9-X9N5-TTB-Oujn8LfEMZkRo3g55lOo=.ddbe0256-98ce-41cf-b03d-94a901237720@github.com>

On Wed, 29 Nov 2023 09:11:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 582:
> 
>> 580:         TableColumn aColumn;
>> 581:         int columnWidth;
>> 582:         boolean ltrFlag = table.getComponentOrientation().isLeftToRight();
> 
> Is SynthTableUI change needed? Seems like your test is passing for Nimbus L&F even without this file change

It is required in synth, it will fail without the fix. And I hope it applies for GTK also.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1409270203

From tr at openjdk.org  Wed Nov 29 13:40:16 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 29 Nov 2023 13:40:16 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v8]
In-Reply-To: <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>
 <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>
Message-ID: <3v6SNykGXUIETUE6opDmFtV4Gh2WIBQ5j1fL6-Knqwo=.2cf04a76-4a26-4c47-8074-c977f831fd98@github.com>

On Wed, 29 Nov 2023 09:10:56 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicTableUI.java line 2033:
> 
>> 2031:             for (int row = rMin; row <= rMax; row++) {
>> 2032:                 y += table.getRowHeight(row);
>> 2033:                 SwingUtilities2.drawHLine(g, damagedArea.x, damagedArea.x + tableWidth - 1, y - 1);
> 
> Is this needed? seems like it's working even without this change..

Yeah, I think so, now since we have modified `JTable.getCellRect`, x position should be handled there. let me remove it and test....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1409295322

From kcr at openjdk.org  Wed Nov 29 16:00:16 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Nov 2023 16:00:16 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <r9veZ2oSoZVgmSqMff238EIEiCLWw-Uh5b0-vFhXj-M=.068b8110-c88b-4692-9912-46eea56f710e@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
 <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
 <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>
 <GYl77levqVWWjHspziWqYk4F9ZT1KI_dE4pURDcwjeo=.935c7d09-ad4c-4cc3-aba8-49db69ac9fdd@github.com>
 <Jvz7UsJV11B3q9eAFquhXVbnalK_KZyiX5wWJSmKnvA=.fe3a1a6f-4fec-4cdc-8713-9036669c60c9@github.com>
 <NNxHlMySTPT52pVJ5bymGz4ayCTZefaaacy
 SkqL18so=.4c214ac7-71d9-46d3-8489-050143bba743@github.com>
 <r9veZ2oSoZVgmSqMff238EIEiCLWw-Uh5b0-vFhXj-M=.068b8110-c88b-4692-9912-46eea56f710e@github.com>
Message-ID: <GgJo1WEP5kO-b-Sxga3iKvmiFvvt62W3eVKDBXEpUiY=.cde687ee-0588-4f52-a657-51aa7b0f38e3@github.com>

On Wed, 29 Nov 2023 07:14:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I found a reason in one comment above.
>
> I guess the code [ApplicationDelegate.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m#L118C4-L128C33) should be changed. Right now it has some checks to prevent "double initialization", but it should take care about the case if the delegate is set already by some external lib. 
> Leaving that as null and skip it in the code means that part of the API will stop working, mostly java.awt.desktop package?

I don't think any further changes are needed to this PR. It's already the case that if another toolkit or the app itself initializes the NSApplication, certain things won't be available in AWT. The system menu bar for example will belong to the toolkit that initializes the NSApplication. That was true before this change and it is still true.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1409505240

From kcr at openjdk.org  Wed Nov 29 16:27:10 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Wed, 29 Nov 2023 16:27:10 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v3]
In-Reply-To: <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <b1h1HAhqJP7ojtwtn29sa4lAImmCcqkDTUpO5q0GaxI=.68521d53-38e1-4332-96a7-fd56e7a8330a@github.com>
Message-ID: <PwhRQK5nPkl3X3xVawdkSvcC_zwCPN3o-YU9Dl8Ho8A=.cf4bb7c2-0678-4c60-b04d-53756a6b172a@github.com>

On Tue, 28 Nov 2023 17:42:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
>> 
>> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
>> 
>> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
>> 
>> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
>> 
>> The fix for JDK-8318854 involves:
>> 
>> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
>> 
>> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
>> 
>> - Null checks are added for shared delegate in cases where it can be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
>> 
>> Test scenarios involving JDK and JFX fixes is documented here 
>> [Updated_Test_Scenarios.xlsx](https://github.com/openjdk/jdk/files/13491545/Updated_Test_Scenarios.xlsx)
>> 
>>  
>> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   static vars and null checks

Marked as reviewed by kcr (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16569#pullrequestreview-1755706733

From tr at openjdk.org  Wed Nov 29 16:47:30 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 29 Nov 2023 16:47:30 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v9]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <LOzX3o6AZppWifg7r5B0RVS6PtCPm6OzRoDkgVEKaKo=.8442de0f-e197-4db3-8751-728daf806f9f@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/15de3608..ecb0f329

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=07-08

  Stats: 30 lines in 3 files changed: 8 ins; 5 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/16374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16374/head:pull/16374

PR: https://git.openjdk.org/jdk/pull/16374

From kizune at openjdk.org  Wed Nov 29 16:51:07 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 29 Nov 2023 16:51:07 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode
 on different keyboard layouts [v2]
In-Reply-To: <6rYOTBqZdRNi3o9m2O3S9rdslhDg-lgBLkUs4Yne1p8=.3ad46b75-7ef1-47a9-b8a2-98d4314dde20@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
 <6rYOTBqZdRNi3o9m2O3S9rdslhDg-lgBLkUs4Yne1p8=.3ad46b75-7ef1-47a9-b8a2-98d4314dde20@github.com>
Message-ID: <7347-rDonqPrquaLhQi3zZq8V9UjnvSubji-ZBky-L8=.0145decd-fd6e-4578-ad76-bc8ebee6a165@github.com>

On Tue, 28 Nov 2023 17:46:19 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Updated previous fix (8262945) to work on extendedKeyCodes. Updated AcceleratorTest to use PassFailJFrame instead of Applet
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test to provide information on which key was pressed

Looks good.

-------------

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16664#pullrequestreview-1755766446

From honkar at openjdk.org  Wed Nov 29 17:44:09 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Nov 2023 17:44:09 GMT
Subject: RFR: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning [v2]
In-Reply-To: <r9veZ2oSoZVgmSqMff238EIEiCLWw-Uh5b0-vFhXj-M=.068b8110-c88b-4692-9912-46eea56f710e@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
 <muEqDlpCVQaHubi6apD5aywlWBoCk9xiTX9B77A5obI=.9662cba4-5a87-406e-9d06-6c27f30125c5@github.com>
 <PtTN1jVXXo-RqEBAs73chL7f-Rzdwkf3jmnVAHrRdnQ=.ce4810b4-e6e2-4397-ad70-d439693aef72@github.com>
 <ow3kwew8aBCXjtfoV5zK7WzuA6ecn7v-Osoi9cPPUws=.a7c0ff45-e790-405a-94b8-05b02db8b3ad@github.com>
 <w9tO-Bo_L607foa6euF64toM54cjq0kFEeV5f9CnvrA=.87a114a9-7d3d-4334-afe4-469c8eecfa85@github.com>
 <c9lz--tnMPS1iWuEGeEXWGgDddwx01hM1BLKXv0VB-o=.7444fc05-55b0-48c7-80a9-f8e35eeecd5e@github.com>
 <3Ukhakqz_jtcEHeGyKrvmWEIWJRZ0__a-n5N5UmL1N0=.274351fc-3eaf-4d8a-b19a-63a492f70869@github.com>
 <GJUC-qSXE0raVLu-aRyJZgyYIQQhA_HIYqOSYI0Gq2I=.edaa1cd6-f01d-4625-b63f-7942a872fb7a@github.com>
 <GYl77levqVWWjHspziWqYk4F9ZT1KI_dE4pURDcwjeo=.935c7d09-ad4c-4cc3-aba8-49db69ac9fdd@github.com>
 <Jvz7UsJV11B3q9eAFquhXVbnalK_KZyiX5wWJSmKnvA=.fe3a1a6f-4fec-4cdc-8713-9036669c60c9@github.com>
 <NNxHlMySTPT52pVJ5bymGz4ayCTZefaaacy
 SkqL18so=.4c214ac7-71d9-46d3-8489-050143bba743@github.com>
 <r9veZ2oSoZVgmSqMff238EIEiCLWw-Uh5b0-vFhXj-M=.068b8110-c88b-4692-9912-46eea56f710e@github.com>
Message-ID: <Oesztm_XSqkwDEQlu_vMOUi5XQ2O859OMV2RkrfeZy4=.a51135fe-3071-4518-b4a2-8aea3b6700a6@github.com>

On Wed, 29 Nov 2023 07:14:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I found a reason in one comment above.
>
> I guess the code [ApplicationDelegate.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m#L118C4-L128C33) should be changed. Right now it has some checks to prevent "double initialization", but it should take care about the case if the delegate is set already by some external lib. 
> Leaving that as null and skip it in the code means that part of the API will stop working, mostly java.awt.desktop package?

@mrserb 

The question as to whether sharedDelegate can be null is answered as part of https://github.com/openjdk/jdk/pull/16569#discussion_r1399559545.

> I guess the code [ApplicationDelegate.m](https://github.com/openjdk/jdk/blob/5493f5f92d569d8e94d1f271480f11c48257e896/src/java.desktop/macosx/native/libawt_lwawt/awt/ApplicationDelegate.m#L118C4-L128C33) should be changed. Right now it has some checks to prevent "double initialization", but it should take care about the case if the delegate is set already by some external lib.
Leaving that as null and skip it in the code means that part of the API will stop working, mostly java.awt.desktop package?

As Kevin explained it earlier, it would be the responsibility of the toolkit that initialized NSApp to add system menu bar, dock menu (if any). This has been tested using variations of sample programs added to [JDK-8318854](https://bugs.openjdk.org/browse/JDK-8318854).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16569#discussion_r1409655375

From vdyakov at openjdk.org  Wed Nov 29 18:28:06 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Wed, 29 Nov 2023 18:28:06 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode
 on different keyboard layouts [v2]
In-Reply-To: <kSSGyw3_Dyx3zcceRFIQ1ekh_6xC5m0Z8hZfoglgPy0=.4ebba018-b261-44ef-becb-e2c216dd9cba@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
 <kSSGyw3_Dyx3zcceRFIQ1ekh_6xC5m0Z8hZfoglgPy0=.4ebba018-b261-44ef-becb-e2c216dd9cba@github.com>
Message-ID: <ZsPc7WB1PJbvUv2kHnAjXdZuLoIbbjefn-szXl8wlIE=.114fdd67-429d-41d0-af5d-2f32c06ec577@github.com>

On Thu, 16 Nov 2023 18:24:07 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   updated test to provide information on which key was pressed
>
> test/jdk/java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java line 1:
> 
>> 1: /*
> 
> Is it possible to print which particular event fired? It could be useful for debugging.
> 
> I'd create a list of `Action`s with the names and shortcuts (as a KeyStroke and as string for printing) and then print each action name with corresponding shortcut. Or create a list of objects with corresponding data. I didn't think it through.

@aivanov-jdk please review

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16664#discussion_r1409704513

From vdyakov at openjdk.org  Wed Nov 29 18:29:06 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Wed, 29 Nov 2023 18:29:06 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab
In-Reply-To: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
Message-ID: <Xm6vyb8RYAfSJIvUJLgc2z1QEqE0O5MbYyZXa2QnxiM=.03de22b6-5aca-4417-be16-89a1c66df691@github.com>

On Tue, 28 Nov 2023 22:34:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added delays to stabilize test, test passes 50 times consecutively

@azvegint @azuev-java please review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16867#issuecomment-1832472993

From honkar at openjdk.org  Wed Nov 29 18:35:09 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Nov 2023 18:35:09 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab
In-Reply-To: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
Message-ID: <0WMyIhY9rLL_Qfg-5sia7M8QwfnUyzJtDYE9TWyx63g=.ea76cf35-ea0c-4e6e-9393-e8fd014e4a87@github.com>

On Tue, 28 Nov 2023 22:34:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added delays to stabilize test, test passes 50 times consecutively

Changes requested by honkar (Committer).

test/jdk/java/awt/Window/Grab/GrabTest.java line 221:

> 219:         robot.delay(100);
> 220:         robot.mouseRelease(InputEvent.BUTTON1_MASK);
> 221:         Util.waitForIdle(robot);

Can be replaced with BUTTON1_DOWN_MASK.

Has the fix been tested on macOS 14 ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/16867#pullrequestreview-1755956965
PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1409711742

From prr at openjdk.org  Wed Nov 29 19:02:06 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 29 Nov 2023 19:02:06 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab
In-Reply-To: <0WMyIhY9rLL_Qfg-5sia7M8QwfnUyzJtDYE9TWyx63g=.ea76cf35-ea0c-4e6e-9393-e8fd014e4a87@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <0WMyIhY9rLL_Qfg-5sia7M8QwfnUyzJtDYE9TWyx63g=.ea76cf35-ea0c-4e6e-9393-e8fd014e4a87@github.com>
Message-ID: <anEvetswj9RZTYv_EJ9w_N8OHM0mWNMXW4ltMzCTYFc=.306b1845-5b46-4318-93c1-ffcc342bfd09@github.com>

On Wed, 29 Nov 2023 18:32:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> test/jdk/java/awt/Window/Grab/GrabTest.java line 221:
> 
>> 219:         robot.delay(100);
>> 220:         robot.mouseRelease(InputEvent.BUTTON1_MASK);
>> 221:         Util.waitForIdle(robot);
> 
> Can be replaced with BUTTON1_DOWN_MASK.
> 
> Has the fix been tested on macOS 14 ?

That (about macOS 14) is the important question. Why is it so unstable on macOS 14 but fine everywhere else ?

Also can't you use "setAutoDelay(100)" instead of adding all these one-off delays ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1409742126

From prr at openjdk.org  Wed Nov 29 19:11:06 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 29 Nov 2023 19:11:06 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text
In-Reply-To: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
Message-ID: <CQSziX92y40YHl3zE5z8_unyGQt3wsb3hVfOsK7sQ0c=.3f7d6354-63cf-4c6b-90c2-3ff56dce9807@github.com>

On Tue, 28 Nov 2023 23:40:45 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
> 
> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning. In addition, a new line is added to BasicLookAndFeel (since Metal derives its default button margin here) to better document the difference in button margins compared to other L&Fs.

src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java line 464:

> 462:      * <p>
> 463:      * The default button margin value is (2, 14, 2, 14), which may
> 464:      * greatly differ from other LookAndFeel defaults.

This will need a CSR, which is fine.
But
(1) Basic is an abstract L&F .. it can't be the place to say what Metal does since most L&Fs derive from Basic
And something about a JButton ought to be closer to ButtonUI or JButton.
(2) Do we have precedent for calling out the exact number of (user space) pixels ?
I'd prefer some more waffly wording like 
"The default margins may vary greatly depending on the L&F".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16869#discussion_r1409750661

From aivanov at openjdk.org  Wed Nov 29 19:17:06 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Nov 2023 19:17:06 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode
 on different keyboard layouts [v2]
In-Reply-To: <6rYOTBqZdRNi3o9m2O3S9rdslhDg-lgBLkUs4Yne1p8=.3ad46b75-7ef1-47a9-b8a2-98d4314dde20@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
 <6rYOTBqZdRNi3o9m2O3S9rdslhDg-lgBLkUs4Yne1p8=.3ad46b75-7ef1-47a9-b8a2-98d4314dde20@github.com>
Message-ID: <dTnVrH291Eg6pwPE4e5w0eEP40XxE2n7v2fNmlDpGjQ=.6497e3cb-32cd-4f5e-8acc-3dcdea390f72@github.com>

On Tue, 28 Nov 2023 17:46:19 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Updated previous fix (8262945) to work on extendedKeyCodes. Updated AcceleratorTest to use PassFailJFrame instead of Applet
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test to provide information on which key was pressed

Looks good.

It fixes the issue where shortcuts didn't work correctly.
I can't make the test pass on macOS but it's a different problem.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16664#pullrequestreview-1756033394

From dnguyen at openjdk.org  Wed Nov 29 19:56:06 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Wed, 29 Nov 2023 19:56:06 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text
In-Reply-To: <CQSziX92y40YHl3zE5z8_unyGQt3wsb3hVfOsK7sQ0c=.3f7d6354-63cf-4c6b-90c2-3ff56dce9807@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <CQSziX92y40YHl3zE5z8_unyGQt3wsb3hVfOsK7sQ0c=.3f7d6354-63cf-4c6b-90c2-3ff56dce9807@github.com>
Message-ID: <JHvSZzyhRbWZO1CltK-BlnflaTRsyur6U7usfEangeI=.3d729a73-192b-41e0-9959-0a467810551b@github.com>

On Wed, 29 Nov 2023 19:08:15 GMT, Phil Race <prr at openjdk.org> wrote:

>> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
>> 
>> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning. In addition, a new line is added to BasicLookAndFeel (since Metal derives its default button margin here) to better document the difference in button margins compared to other L&Fs.
>
> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java line 464:
> 
>> 462:      * <p>
>> 463:      * The default button margin value is (2, 14, 2, 14), which may
>> 464:      * greatly differ from other LookAndFeel defaults.
> 
> This will need a CSR, which is fine.
> But
> (1) Basic is an abstract L&F .. it can't be the place to say what Metal does since most L&Fs derive from Basic
> And something about a JButton ought to be closer to ButtonUI or JButton.
> (2) Do we have precedent for calling out the exact number of (user space) pixels ?
> I'd prefer some more waffly wording like 
> "The default margins may vary greatly depending on the L&F".

For (1), I've considered some alternative spots for this note. MetalButtonUI and MetalLookAndFeel for example, but I didn't see any natural spot to add this to. I decided to put it in BasicLookAndFeel since the default value is set here, but I see your point. I can add an additional note in the doc for, say, MetalButtonUI if preferred.

In (2), you're right that there's no explicit pixel count for anything. I'll update this to be more general. Do you think this additional note is enough to avoid adding more doc changes to Metal classes?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16869#discussion_r1409791948

From aivanov at openjdk.org  Wed Nov 29 20:01:07 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 29 Nov 2023 20:01:07 GMT
Subject: RFR: 8315701: [macos] Regression: KeyEvent has different keycode
 on different keyboard layouts [v2]
In-Reply-To: <dTnVrH291Eg6pwPE4e5w0eEP40XxE2n7v2fNmlDpGjQ=.6497e3cb-32cd-4f5e-8acc-3dcdea390f72@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
 <6rYOTBqZdRNi3o9m2O3S9rdslhDg-lgBLkUs4Yne1p8=.3ad46b75-7ef1-47a9-b8a2-98d4314dde20@github.com>
 <dTnVrH291Eg6pwPE4e5w0eEP40XxE2n7v2fNmlDpGjQ=.6497e3cb-32cd-4f5e-8acc-3dcdea390f72@github.com>
Message-ID: <TcaAbcpM4KmHUJwFfcIp5nZVLCnzpWTmbQ5vGvqyU2U=.bc4f3931-8160-4fb9-a9f5-6ab91fc55470@github.com>

On Wed, 29 Nov 2023 19:14:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I can't make the test pass on macOS but it's a different problem.

I've submitted [JDK-8321042](https://bugs.openjdk.org/browse/JDK-8321042): _Test java/awt/event/KeyEvent/AcceleratorTest/AcceleratorTest.java fails on macOS_.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16664#issuecomment-1832614159

From honkar at openjdk.org  Wed Nov 29 21:56:16 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 29 Nov 2023 21:56:16 GMT
Subject: Integrated: JDK-8318854: [macos14] Running any AWT app prints Secure
 coding warning
In-Reply-To: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
References: <NOm-CNdYExWlgZ0ji8h3f4GWNH3aGrFYlWsZHdaJqcE=.c3b76947-447b-47cc-a17c-e4ed0c488726@github.com>
Message-ID: <pj96vxFHONCXtff4wlEwMnZFmWhF2tWktOqPPs67wXk=.996330b2-8c1a-4422-a2b3-77b5cdfde743@github.com>

On Wed, 8 Nov 2023 19:49:48 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> With Xcode upgraded to 14.3.1 for macOS builds secure coding warning message was seen in the logs as below:
> 
> "WARNING: Secure coding is not enabled for restorable state! Enable secure coding by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState: and returning YES."
> 
> which requires AppDelegate to explicitly implement applicationSupportsSecureRestorableState() to return true as mentioned here in [Apple Release notes](https://developer.apple.com/documentation/macos-release-notes/appkit-release-notes-for-macos-14#Restorable-State).
> 
> While investigating JFX embedded scenario (Swing components in FX window) another issue observed was that the AWT was overriding the FX delegate causing the app to crash in certain scenarios. This issue is also being fixed in this PR and also as part of [JDK-8319669](https://bugs.openjdk.org/browse/JDK-8319669) , https://github.com/openjdk/jfx/pull/1280.
> 
> The fix for JDK-8318854 involves:
> 
> - implementing applicationSupportsSecureRestorableState() in ApplicationDelegate.m & QueuingApplicationDelegate.m to return YES  by default, unless the env var - **AWT_DISABLE_NSDELEGATE_SECURE_SAVE**  is defined.
> 
> - Fix added to stop AWT toolkit from overriding a delegate set by another NSApplication by default. There is an option to restore the old behavior by defining the env var - **AWT_OVERRIDE_NSDELEGATE**.
> 
> - Null checks are added for shared delegate in cases where it can be null and cause issues in AWTWindow.m, CMenuBar.m, ApplicationDelegate.m
> 
> Test scenarios involving JDK and JFX fixes is documented here 
> [Updated_Test_Scenarios.xlsx](https://github.com/openjdk/jdk/files/13491545/Updated_Test_Scenarios.xlsx)
> 
>  
> **PLEASE NOTE !!**  The environment variables being added as part of this fix are for debugging only and should NOT be used for application purpose. As such they will NOT be documented.

This pull request has now been integrated.

Changeset: 940f67c1
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/940f67c1a62c6f9462266f3a108649aca114cffa
Stats:     66 lines in 4 files changed: 42 ins; 2 del; 22 mod

8318854: [macos14] Running any AWT app prints Secure coding warning

Reviewed-by: kcr, kizune, prr

-------------

PR: https://git.openjdk.org/jdk/pull/16569

From rkannathpari at openjdk.org  Thu Nov 30 03:40:28 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 30 Nov 2023 03:40:28 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix
Message-ID: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>

Hi Reviewers, 
There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 

Renjith.

-------------

Commit messages:
 - JDK-8316497 : ColorConvertOp - typo for non-ICC conversions needs one-line fix

Changes: https://git.openjdk.org/jdk/pull/16895/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16895&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316497
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16895.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16895/head:pull/16895

PR: https://git.openjdk.org/jdk/pull/16895

From psadhukhan at openjdk.org  Thu Nov 30 04:14:10 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Nov 2023 04:14:10 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v8]
In-Reply-To: <bEPnFCyMAp2x9-X9N5-TTB-Oujn8LfEMZkRo3g55lOo=.ddbe0256-98ce-41cf-b03d-94a901237720@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>
 <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>
 <bEPnFCyMAp2x9-X9N5-TTB-Oujn8LfEMZkRo3g55lOo=.ddbe0256-98ce-41cf-b03d-94a901237720@github.com>
Message-ID: <8KPruIORf6s83XrIfgGTHKgcRIXjKhIY0dMlXmnk0Xc=.22fcce09-3f72-4886-bf04-3d89369e4800@github.com>

On Wed, 29 Nov 2023 13:18:28 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTableUI.java line 582:
>> 
>>> 580:         TableColumn aColumn;
>>> 581:         int columnWidth;
>>> 582:         boolean ltrFlag = table.getComponentOrientation().isLeftToRight();
>> 
>> Is SynthTableUI change needed? Seems like your test is passing for Nimbus L&F even without this file change
>
> It is required in synth, it will fail without the fix. And I hope it applies for GTK also.

Synth provides the base and has no specific use, it is extended and used by Nimbus and GTK L&F..
It passes for me in Nimbus L&F in Windows without Synth**UI change for your testcase and JBS testcase as well..
If it fails in GTK without Synth*UI change, I guess we need to find out why it passing for Nimbus without the change and make necessary change in GTK specifically and not in common class.....
and even if it's needed in Synth, since the code seems to be same, the `paintCells` should call a common method from both Basic and Synth so that if a bug is found it can be fixed at one place

![image](https://github.com/openjdk/jdk/assets/43534309/144769c1-80c7-4df9-87e9-92269467118f)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410132140

From psadhukhan at openjdk.org  Thu Nov 30 04:14:11 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Nov 2023 04:14:11 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v8]
In-Reply-To: <8KPruIORf6s83XrIfgGTHKgcRIXjKhIY0dMlXmnk0Xc=.22fcce09-3f72-4886-bf04-3d89369e4800@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>
 <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>
 <bEPnFCyMAp2x9-X9N5-TTB-Oujn8LfEMZkRo3g55lOo=.ddbe0256-98ce-41cf-b03d-94a901237720@github.com>
 <8KPruIORf6s83XrIfgGTHKgcRIXjKhIY0dMlXmnk0Xc=.22fcce09-3f72-4886-bf04-3d89369e4800@github.com>
Message-ID: <CwpirFP-Nasy_KV_IdjKsEbpJK2U_zI3b7Qhg4RMH7c=.997a39e2-f977-43d0-9d97-b5bc1a733005@github.com>

On Thu, 30 Nov 2023 04:10:37 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> It is required in synth, it will fail without the fix. And I hope it applies for GTK also.
>
> Synth provides the base and has no specific use, it is extended and used by Nimbus and GTK L&F..
> It passes for me in Nimbus L&F in Windows without Synth**UI change for your testcase and JBS testcase as well..
> If it fails in GTK without Synth*UI change, I guess we need to find out why it passing for Nimbus without the change and make necessary change in GTK specifically and not in common class.....
> and even if it's needed in Synth, since the code seems to be same, the `paintCells` should call a common method from both Basic and Synth so that if a bug is found it can be fixed at one place
> 
> ![image](https://github.com/openjdk/jdk/assets/43534309/144769c1-80c7-4df9-87e9-92269467118f)

Infact, it seems the regression testcase and JBS testcase passes in windows just with JTable change only ie even without BasicTableUI change...Can you check?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410132549

From tr at openjdk.org  Thu Nov 30 04:57:09 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 30 Nov 2023 04:57:09 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v8]
In-Reply-To: <CwpirFP-Nasy_KV_IdjKsEbpJK2U_zI3b7Qhg4RMH7c=.997a39e2-f977-43d0-9d97-b5bc1a733005@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <Dp6wTXaZ15wtOUXi9D2zv6rgn6wXQ1z_p5tjrO5fqaY=.a1f9f630-6431-4ef3-9715-0c757d6014c6@github.com>
 <eJGuD9JDlgKKJPixsF5RDkH72vjBEPdc6W_ivmKZuvo=.9ab6dcef-ca70-445f-b5f3-3fd394b9d5d1@github.com>
 <bEPnFCyMAp2x9-X9N5-TTB-Oujn8LfEMZkRo3g55lOo=.ddbe0256-98ce-41cf-b03d-94a901237720@github.com>
 <8KPruIORf6s83XrIfgGTHKgcRIXjKhIY0dMlXmnk0Xc=.22fcce09-3f72-4886-bf04-3d89369e4800@github.com>
 <CwpirFP-Nasy_KV_IdjKsEbpJK2U_zI3b7Qhg4RMH7c=.997a39e2-f977-43d0-9d97-b5bc1a733005@github.com>
Message-ID: <mAhURbrRpR0D5OL46k2vhAqNE00Xa_bL6brODYQ1JVE=.ccba2d1a-1a5b-4af5-a8ea-a40724632024@github.com>

On Thu, 30 Nov 2023 04:11:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Synth provides the base and has no specific use, it is extended and used by Nimbus and GTK L&F..
>> It passes for me in Nimbus L&F in Windows without Synth**UI change for your testcase and JBS testcase as well..
>> If it fails in GTK without Synth*UI change, I guess we need to find out why it passing for Nimbus without the change and make necessary change in GTK specifically and not in common class.....
>> and even if it's needed in Synth, since the code seems to be same, the `paintCells` should call a common method from both Basic and Synth so that if a bug is found it can be fixed at one place
>> 
>> ![image](https://github.com/openjdk/jdk/assets/43534309/144769c1-80c7-4df9-87e9-92269467118f)
>
> Infact, it seems the regression testcase and JBS testcase passes in windows just with JTable change only ie even without BasicTableUI change...Can you check?

Yeah, looks like the only change required was in JTable...... Will test and update......

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410153261

From azvegint at openjdk.org  Thu Nov 30 07:25:06 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 30 Nov 2023 07:25:06 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab
In-Reply-To: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
Message-ID: <PiexOSh7WrxLPRmBmJPSBiTwO8jcGLjbMRLW-jDqEJs=.d0c0eb6c-fb1d-4818-8676-3c697c4ad3ae@github.com>

On Tue, 28 Nov 2023 22:34:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added delays to stabilize test, test passes 50 times consecutively

test/jdk/java/awt/Window/Grab/GrabTest.java line 118:

> 116: 
> 117:         f.setVisible(true);
> 118:         w.setVisible(true);

Since you are already touching this test, all the GUI work can be moved to the EDT.

test/jdk/java/awt/Window/Grab/GrabTest.java line 119:

> 117:         f.setVisible(true);
> 118:         w.setVisible(true);
> 119:         Util.waitForIdle(robot);

Adding a delay could also improve the test stability (as you already did on lines 247 and 253). 
However, our usual practice is to add a 500-1000 ms delay after showing a frame to make it work even on really slow machines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1410250980
PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1410223413

From tr at openjdk.org  Thu Nov 30 08:08:33 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 30 Nov 2023 08:08:33 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v10]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <bQ9jvjmrkT463GTw5whDs0xu1-lnQJwH3cqhpgDS2AA=.13c6c0f5-63bf-4a21-96bf-ff2112b101a1@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/ecb0f329..1272081f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=08-09

  Stats: 83 lines in 2 files changed: 32 ins; 25 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/16374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16374/head:pull/16374

PR: https://git.openjdk.org/jdk/pull/16374

From psadhukhan at openjdk.org  Thu Nov 30 09:15:23 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 30 Nov 2023 09:15:23 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v10]
In-Reply-To: <bQ9jvjmrkT463GTw5whDs0xu1-lnQJwH3cqhpgDS2AA=.13c6c0f5-63bf-4a21-96bf-ff2112b101a1@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <bQ9jvjmrkT463GTw5whDs0xu1-lnQJwH3cqhpgDS2AA=.13c6c0f5-63bf-4a21-96bf-ff2112b101a1@github.com>
Message-ID: <Wv2e8TFw7i_9yvPIprMKP3t5x1t_xjIRpNC-HSAKrSM=.34a89ab7-2dbd-4612-8e7d-40f6313b132b@github.com>

On Thu, 30 Nov 2023 08:08:33 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

src/java.desktop/share/classes/javax/swing/JTable.java line 3013:

> 3011:             }
> 3012:             if( !getComponentOrientation().isLeftToRight() ) {
> 3013:                 r.x = getWidthInRightToLeft() - r.x - cm.getColumn(column).getWidth();

It will be good to add comments explaining why you are doing what you are doing for future recall and
more is less here...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410372463

From tr at openjdk.org  Thu Nov 30 10:03:47 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 30 Nov 2023 10:03:47 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v11]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/1272081f..8286bce7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=09-10

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16374/head:pull/16374

PR: https://git.openjdk.org/jdk/pull/16374

From aivanov at openjdk.org  Thu Nov 30 12:44:24 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 12:44:24 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v11]
In-Reply-To: <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>
Message-ID: <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>

On Thu, 30 Nov 2023 10:03:47 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JTable.java line 3013:

> 3011:             }
> 3012:             //x position is updated to handled the offset to which the table
> 3013:             //has to be moved towards right side in right-to-left Orientation.

Suggestion:

            // x position is updated to take into account the offset to
            // which the table column is moved in the right-to-left orientation.

I still don't like any variant because it doesn't clarify the main point: _the columns are laid out starting from the right side_.

src/java.desktop/share/classes/javax/swing/JTable.java line 3017:

> 3015:                 r.x = getWidthInRightToLeft() - r.x - cm.getColumn(column).getWidth();
> 3016:             }
> 3017:             r.width = cm.getColumn(column).getWidth();

Suggestion:

            final int columnWidth = cm.getColumn(column).getWidth();
            if( !getComponentOrientation().isLeftToRight() ) {
                r.x = getWidthInRightToLeft() - r.x - columnWidth;
            }
            r.width = columnWidth;

Just to avoid getting the same value twice.

src/java.desktop/share/classes/javax/swing/JTable.java line 9809:

> 9807:         }
> 9808:         return super.getWidth();
> 9809:     }

Can you elaborate on why it's needed? Presumably both versions return the same width because `JTable` doesn't override `getWidth`.

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 48:

> 46: import java.io.IOException;
> 47: import java.util.ArrayList;
> 48: import java.util.List;

I wonder why these imports are below `javax.*`, it is very uncommon.

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 55:

> 53:  * @bug 5108458
> 54:  * @summary Test to check Right alignment of JTable data
> 55:  * (Fix affects all L&F, test verifies only Metal L&F)

Suggestion:


This line doesn't apply any longer.

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 73:

> 71:             try {
> 72:                 SwingUtilities.invokeAndWait(() -> {
> 73:                     frame = new JFrame("Test JTable");

Be more specific:
Suggestion:

                    frame = new JFrame("JTable RTL column layout");

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 97:

> 95:                     }
> 96:                     tableLocation = customTableObj.table.getLocationOnScreen();
> 97:                     tableSize = customTableObj.table.getSize();

Perform all the calculation here and publish the object with the result:

Suggestion:

                    int allColumnWidths = 0;
                    for (int i = 0; i < customTableObj.table.getColumnCount(); i++) {
                        allColumnWidths += customTableObj.table.getTableHeader().getColumnModel()
                                .getColumn(i)
                                .getWidth();
                    }
                    Point tableLocation = customTableObj.table.getLocationOnScreen();
                    Dimension tableSize = customTableObj.table.getSize();
                    tableSize.width -= allColumnWidths;

                    tableBounds = new Rectangle(tableLocation, tableSize);

where `tableBounds` is a `static volatile` field of type `Rectangle` that needs to be declared instead of the three fields `allColumnWidths`, `tableLocation`, `tableSize` which has now become local variables.

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 104:

> 102:                                 tableLocation.y,
> 103:                                 (int)tableSize.getWidth() - allColumnWidths,
> 104:                                 (int)tableSize.getHeight()));

Suggestion:

                BufferedImage bufferedImage = robot.createScreenCapture(tableBounds);


This is much cleaner, isn't it?

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 130:

> 128:     private static void saveImage(BufferedImage image, String fileName) {
> 129:         try {
> 130:             ImageIO.write(image, "png", new File(fileName));

Suggestion:

            ImageIO.write(image, "png", new File("failureImage.png"));

Perhaps, you can inline the file name? It never changes.

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 148:

> 146: }
> 147: 
> 148: class CustomTable {

I still think `CustomTable` is a bad name for this class because it represents table model. It requires further refactoring to clean up the code but I won't insist on doing so.

Even though it's only test code and therefore it shouldn't be as robust and clean as product code, I believe it's important to keep the test code clean as well so that tests can serve as samples. Any ways?

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 151:

> 149:     public final static int COL_FIRSTNAME = 0;
> 150:     public final static int COL_LASTNAME = 1;
> 151:     public final static int COL_SALARY = 2;

Suggestion:

    private static final int COL_FIRSTNAME = 0;
    private static final int COL_LASTNAME = 1;
    private static final int COL_SALARY = 2;

Let's use the blessed modifier order; these can be `private`.

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 153:

> 151:     public final static int COL_SALARY = 2;
> 152: 
> 153:     static final Class[] classes = {

Suggestion:

    static final Class<?>[] classes = {

Let's get rid of raw types. The test code was presumably written before generics were introduced into Java.

test/jdk/javax/swing/JTable/JTableRightOrientationTest.java line 206:

> 204:         }
> 205: 
> 206:         public Class getColumnClass(int columnIndex) {

Suggestion:

        public Class<?> getColumnClass(int columnIndex) {

-------------

PR Review: https://git.openjdk.org/jdk/pull/16374#pullrequestreview-1757169103
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410497393
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410615475
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410613628
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410580754
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410582328
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410616870
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410586207
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410588365
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410589855
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410604922
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410591553
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410592492
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410593653

From aivanov at openjdk.org  Thu Nov 30 14:10:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 14:10:16 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v11]
In-Reply-To: <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>
 <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>
Message-ID: <c_DqGbOor4WUPIZ3yxlQRk9SU83_jfgdseoU7SLbhCs=.054d8337-4484-4437-becd-96169354d5fe@github.com>

On Thu, 30 Nov 2023 10:52:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 3013:
> 
>> 3011:             }
>> 3012:             //x position is updated to handled the offset to which the table
>> 3013:             //has to be moved towards right side in right-to-left Orientation.
> 
> Suggestion:
> 
>             // x position is updated to take into account the offset to
>             // which the table column is moved in the right-to-left orientation.
> 
> I still don't like any variant because it doesn't clarify the main point: _the columns are laid out starting from the right side_.

What about: _Table columns are laid out from right to left if component orientation is set to ComponentOrientation.RIGHT_TO_LEFT; adjust the x coordinate for this case._

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410724356

From achung at openjdk.org  Thu Nov 30 16:14:28 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 30 Nov 2023 16:14:28 GMT
Subject: Integrated: 8315701: [macos] Regression: KeyEvent has different
 keycode on different keyboard layouts
In-Reply-To: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
References: <c_mBumQacuCH0qB5N-JMNOfsu5YGAdp6NZ4QVywHIpc=.0a5e6303-c6e2-45f3-a890-df3ef17f7f96@github.com>
Message-ID: <wgQxd49HDtaI890gNaMwsxrxnbVjJyBnMOtGywTzG6w=.8c08fb34-a4c5-4467-9f66-a4acb9817e2d@github.com>

On Tue, 14 Nov 2023 21:22:37 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updated previous fix (8262945) to work on extendedKeyCodes. Updated AcceleratorTest to use PassFailJFrame instead of Applet

This pull request has now been integrated.

Changeset: a3eb6640
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3eb6640773620331692da40356522ff618c3c44
Stats:     434 lines in 7 files changed: 91 ins; 264 del; 79 mod

8315701: [macos] Regression: KeyEvent has different keycode on different keyboard layouts

Reviewed-by: aivanov, kizune

-------------

PR: https://git.openjdk.org/jdk/pull/16664

From dnguyen at openjdk.org  Thu Nov 30 16:32:31 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 30 Nov 2023 16:32:31 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v2]
In-Reply-To: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
Message-ID: <_dkwxfsAMwrTGiuWTXszFNkltVFUR2aySTzVb5ZlsyM=.286343d1-c71b-43f6-864d-168aa6147a48@github.com>

> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
> 
> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning. In addition, a new line is added to BasicLookAndFeel (since Metal derives its default button margin here) to better document the difference in button margins compared to other L&Fs.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Update doc change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16869/files
  - new: https://git.openjdk.org/jdk/pull/16869/files/33de9ff7..b843a749

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16869&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16869&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16869.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16869/head:pull/16869

PR: https://git.openjdk.org/jdk/pull/16869

From tr at openjdk.org  Thu Nov 30 17:06:19 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 30 Nov 2023 17:06:19 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v11]
In-Reply-To: <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>
 <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>
Message-ID: <7gEx6NNJchYlCUiN1b2n_Vf_MyNf_REtW--NOiOoCQ4=.46444e22-e6e2-4b70-acf5-cda54388b66d@github.com>

On Thu, 30 Nov 2023 12:37:37 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 9809:
> 
>> 9807:         }
>> 9808:         return super.getWidth();
>> 9809:     }
> 
> Can you elaborate on why it's needed? Presumably both versions return the same width because `JTable` doesn't override `getWidth`.

I actually reused it from `JTableHeader` class and yeah it will be `parent.getWidth ` always as of now, but I thought it might be for future purpose, but not sure... Should we retain or just use `parent.getWidth` directly?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1410974627

From tr at openjdk.org  Thu Nov 30 17:20:40 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 30 Nov 2023 17:20:40 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v12]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <iUCvuU4dxmjJrPXbs6FMcf9MhagEjnfbG4ZV7PjumlI=.3dd138a7-65a0-45b8-a138-13d600e32f81@github.com>

> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
> CI tested is green for regression check and test check.

Tejesh R has updated the pull request incrementally with one additional commit since the last revision:

  Review fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/8286bce7..9fab11f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=10-11

  Stats: 39 lines in 2 files changed: 8 ins; 12 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/16374.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16374/head:pull/16374

PR: https://git.openjdk.org/jdk/pull/16374

From aivanov at openjdk.org  Thu Nov 30 17:22:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 17:22:12 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <zOg35G9S05wsck3K-Ps2-g0wcFUQS8KekSmCjBY9oTE=.266b65ca-cb70-4cf6-be32-48ca332ef886@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
 <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com>
 <zOg35G9S05wsck3K-Ps2-g0wcFUQS8KekSmCjBY9oTE=.266b65ca-cb70-4cf6-be32-48ca332ef886@github.com>
Message-ID: <gDO8hsy8vsBusp1HEut4bMarcgsiFCKeiR33e1MstC4=.57dc2b52-c799-480a-b01f-72396f24d440@github.com>

On Mon, 27 Nov 2023 18:48:52 GMT, Phil Race <prr at openjdk.org> wrote:

>> I see `SetOrient.java` has its sibling `SetOrient.html` where you added `@key printer`.
>> 
>> Since both files contain all the tags except for `@test` in the .java file, you should not remove the `@run` tag from the .java file and add `@key printer` to it.
>
> "Should not" is strong. Why ? There's no requirement do to this even though you can.
> https://openjdk.org/jtreg/faq.html#can-i-use-the-author-run-etc.-tags-in-other-files

That's the reason why I prefer you keep the `@run` tag in `SetOrient.java`: to document that it's *an applet test* ? with the html file being the test starter.

> I saw that, and it didn't fail at all on mac for any case.  
> Not sure how much I want to get dragged into fixing the test, and there's no bug id to refer back to.

I'd like to make the test useful and ensure it tests the conditions it was written for. This is why I submitted a separate bug for fixing the test ? it's out of scope for the current PR.

The test was written for [JDK-4250681](https://bugs.openjdk.org/browse/JDK-4250681): PrinterJob.print() generates IllegalArgumentException,NegativeArraySizeException.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410861731
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410962571

From aivanov at openjdk.org  Thu Nov 30 17:22:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 17:22:16 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <jBqUQxZE78tdoPFlZy8uhjpen-y_JxMi2RLoPlTNhCk=.f30a3a7a-91b2-4479-a788-e050f412b2cf@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
 <jBqUQxZE78tdoPFlZy8uhjpen-y_JxMi2RLoPlTNhCk=.f30a3a7a-91b2-4479-a788-e050f412b2cf@github.com>
Message-ID: <yqCei996OnlAZkKdVZXMF-537BicGf3N4w8VY2ep7DM=.e2ae544b-305d-4e51-a4b7-4747702c50dd@github.com>

On Mon, 27 Nov 2023 18:53:24 GMT, Phil Race <prr at openjdk.org> wrote:

> I can .. but I am not aware of even a convention to do that ordering.

It's not written anywhere as far as I know. There's [an ongoing discussion](https://github.com/openjdk/jdk/pull/16674#discussion_r1402082665) about it in #16674.

<q cite="https://github.com/openjdk/jdk/pull/16674#discussion_r1402082665">If the jtreg tags are placed in a comment that precedes the class declaration, after the imports, they're not collapsed ? you can see them right away without scrolling or clicking. I consider the jtreg tags quite relevant to see them easily.</q>

I see no benefits to keeping the jtreg tags before the imports where they're collapsed together with the copyright header. At the same time, I see the value in placing them below imports.

> I'll update the imports in this file since I touched it more than any other case

It's the reason why I asked for it; modifications in this file aren't limited to `@key` or `@author` tags.

>> test/jdk/java/awt/print/PrinterJob/PrintAllFonts.java line 26:
>> 
>>> 24: /**
>>> 25:  *
>>> 26:  * @bug 4884389 7183516
>> 
>> Is it intentional that there's no `@test` tag?
>
> I think this is another test that needs some work. It doesn't wait to see if the user gave it a pass.
> I'll add "test" but not "@test".

Ah, I see, it falls into the same category as all the tests in [JDK-8320676](https://bugs.openjdk.org/browse/JDK-8320676) which use the `Sysout` framework. I didn't include it because it doesn't have `@test` and therefore it can't be run.

I added a comment about the test, it's not worth filing its own bug at this point.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410944165
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411000260

From aivanov at openjdk.org  Thu Nov 30 17:22:21 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 17:22:21 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <YK2EQtIP0-86eeLa1lOndwrMzuQ3uEh1VSIzmag1QrM=.21a33860-a201-48de-8be6-2b4c31fc5aa4@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <YK2EQtIP0-86eeLa1lOndwrMzuQ3uEh1VSIzmag1QrM=.21a33860-a201-48de-8be6-2b4c31fc5aa4@github.com>
Message-ID: <lx0Q9LrQEu_whvnQMhC1het6OFoqnq8h527sD82ttYo=.f5e0d895-a103-46ec-8a5d-7c6d19d7417c@github.com>

On Mon, 27 Nov 2023 20:20:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320608

test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 73:

> 71:           job.print();
> 72:       }
> 73:       catch (PrinterException e) {

Suggestion:

      } catch (PrinterException e) {

The `catch` keyword should be on the line with the closing brace of the `try {}` block.

It can be addressed in [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671) when the test is updated.

test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 72:

> 70:            return;
> 71:        }
> 72:        PrinterJob pj = PrinterJob.getPrinterJob();

It looks good, however, I'd move the blank so that the code groups logically:


       StreamPrintService svc = spfs[0].getPrintService(baos);
       if (svc == null) {
           return;
       }

       PrinterJob pj = PrinterJob.getPrinterJob();


Perhaps, the test should fail if `svc` happens to be `null`, after all it's quite unexpected if it's `null`, isn't it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410886948
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1410980732

From aivanov at openjdk.org  Thu Nov 30 17:37:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 17:37:12 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <YK2EQtIP0-86eeLa1lOndwrMzuQ3uEh1VSIzmag1QrM=.21a33860-a201-48de-8be6-2b4c31fc5aa4@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <YK2EQtIP0-86eeLa1lOndwrMzuQ3uEh1VSIzmag1QrM=.21a33860-a201-48de-8be6-2b4c31fc5aa4@github.com>
Message-ID: <7ClPt0yP816O2BNX_DvPUnLyXJAjk7yUpdLSqtjTgtU=.bd31651d-4500-4605-98d1-9212e648f290@github.com>

On Mon, 27 Nov 2023 20:20:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320608

Looks good to me  
?except for some minor comments.

test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 28:

> 26:  * @bug 4459889
> 27:  * @summary No NullPointerException should occur.
> 28:  * @key printer

Suggestion:

 * @test
 * @bug 4459889
 * @key printer
 * @summary No NullPointerException should occur.

To be consistent with other tests.

-------------

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1758016744
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411002236

From aivanov at openjdk.org  Thu Nov 30 17:47:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 17:47:20 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v11]
In-Reply-To: <7gEx6NNJchYlCUiN1b2n_Vf_MyNf_REtW--NOiOoCQ4=.46444e22-e6e2-4b70-acf5-cda54388b66d@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>
 <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>
 <7gEx6NNJchYlCUiN1b2n_Vf_MyNf_REtW--NOiOoCQ4=.46444e22-e6e2-4b70-acf5-cda54388b66d@github.com>
Message-ID: <erik8G-cOH9jtt6ODfV1kMvHrE2nQrdjsFr1L-xb1G8=.7bd0c1f3-4b2c-49dc-b4eb-0debefc255b2@github.com>

On Thu, 30 Nov 2023 17:03:00 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JTable.java line 9809:
>> 
>>> 9807:         }
>>> 9808:         return super.getWidth();
>>> 9809:     }
>> 
>> Can you elaborate on why it's needed? Presumably both versions return the same width because `JTable` doesn't override `getWidth`.
>
> I actually reused it from `JTableHeader` class and yeah it will be `parent.getWidth ` always as of now, but I thought it might be for future purpose, but not sure... Should we retain or just use `parent.getWidth` directly?

You don't call `parent.getWidth()` here, you always call `this.getWidth()`.

I don't know why `JTableHeader` has special handling for it? Yet in the case of `JTableHeader` it may be reasonable: the header follows the table width if it's auto-resizable. I presume the table handles this mode somehow.

> I thought it might be for future purpose, but not sure... Should we retain or just use `parent.getWidth` directly?

In both cases, you call the same implementation of `getWidth`. I'm for removing the `getWidthInRightToLeft` method altogether unless there's a specific purpose for doing it, which I can't see ? use `getWidth` directly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1411060721

From aivanov at openjdk.org  Thu Nov 30 17:47:21 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 17:47:21 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v11]
In-Reply-To: <erik8G-cOH9jtt6ODfV1kMvHrE2nQrdjsFr1L-xb1G8=.7bd0c1f3-4b2c-49dc-b4eb-0debefc255b2@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>
 <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>
 <7gEx6NNJchYlCUiN1b2n_Vf_MyNf_REtW--NOiOoCQ4=.46444e22-e6e2-4b70-acf5-cda54388b66d@github.com>
 <erik8G-cOH9jtt6ODfV1kMvHrE2nQrdjsFr1L-xb1G8=.7bd0c1f3-4b2c-49dc-b4eb-0debefc255b2@github.com>
Message-ID: <3c-r5WZdBvId2JwggeBMWEuO5Ac1FCsMm2614_mdcPI=.cc31ff34-75eb-4e69-a7d8-d20009e0e18a@github.com>

On Thu, 30 Nov 2023 17:44:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I actually reused it from `JTableHeader` class and yeah it will be `parent.getWidth ` always as of now, but I thought it might be for future purpose, but not sure... Should we retain or just use `parent.getWidth` directly?
>
> You don't call `parent.getWidth()` here, you always call `this.getWidth()`.
> 
> I don't know why `JTableHeader` has special handling for it? Yet in the case of `JTableHeader` it may be reasonable: the header follows the table width if it's auto-resizable. I presume the table handles this mode somehow.
> 
>> I thought it might be for future purpose, but not sure... Should we retain or just use `parent.getWidth` directly?
> 
> In both cases, you call the same implementation of `getWidth`. I'm for removing the `getWidthInRightToLeft` method altogether unless there's a specific purpose for doing it, which I can't see ? use `getWidth` directly.

Did you test RTL with auto-resizing table?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1411061421

From aivanov at openjdk.org  Thu Nov 30 17:51:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 17:51:20 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v12]
In-Reply-To: <iUCvuU4dxmjJrPXbs6FMcf9MhagEjnfbG4ZV7PjumlI=.3dd138a7-65a0-45b8-a138-13d600e32f81@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <iUCvuU4dxmjJrPXbs6FMcf9MhagEjnfbG4ZV7PjumlI=.3dd138a7-65a0-45b8-a138-13d600e32f81@github.com>
Message-ID: <IGl4vMhBhs8St_plbX4YKZ5S-Yhh94toFLA9103XgnA=.2a5f5f5f-925e-420a-9423-246c9c018957@github.com>

On Thu, 30 Nov 2023 17:20:40 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Table contents does not follow right-left Orientation when Max width of columns are set. This is due to not considering the offset in `x position` while painting table grid and table cell. The fix handles the offset and adjust the x position for each paint, similar to how header is painted. The fix is applied to both Basic and Synth Look and Feel. 
>> The fix is verified for all Look and Feel manually and test verifies on Metal L&F since automatic test cannot be generalized throughout other Look and Feel. 
>> CI tested is green for regression check and test check.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fix

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JTable.java line 3014:

> 3012:             //Table columns are laid out from right to left when component
> 3013:             //orientation is set to ComponentOrientation.RIGHT_TO_LEFT,
> 3014:             //adjust the x coordinate for this case.

Suggestion:

            // Table columns are laid out from right to left when component
            // orientation is set to ComponentOrientation.RIGHT_TO_LEFT,
            // adjust the x coordinate for this case.

There's usually a space, it improves readability, just search for `//` in `JTable.java`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/16374#pullrequestreview-1758119254
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1411063743

From prr at openjdk.org  Thu Nov 30 18:18:06 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Nov 2023 18:18:06 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <gDO8hsy8vsBusp1HEut4bMarcgsiFCKeiR33e1MstC4=.57dc2b52-c799-480a-b01f-72396f24d440@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
 <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com>
 <zOg35G9S05wsck3K-Ps2-g0wcFUQS8KekSmCjBY9oTE=.266b65ca-cb70-4cf6-be32-48ca332ef886@github.com>
 <gDO8hsy8vsBusp1HEut4bMarcgsiFCKeiR33e1MstC4=.57dc2b52-c799-480a-b01f-72396f24d440@github.com>
Message-ID: <jaqlZsvnTS9Mn1AQ0DWXjJIgW141P6kbAKgjp5BI3JM=.271036c4-d14d-42d4-ad43-9d1827e8fc9e@github.com>

On Thu, 30 Nov 2023 15:41:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> "Should not" is strong. Why ? There's no requirement do to this even though you can.
>> https://openjdk.org/jtreg/faq.html#can-i-use-the-author-run-etc.-tags-in-other-files
>
> That's the reason why I prefer you keep the `@run` tag in `SetOrient.java`: to document that it's *an applet test* ? with the html file being the test starter.

Ok, although when I see something like that it looks more like a bug to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411093305

From prr at openjdk.org  Thu Nov 30 18:18:10 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Nov 2023 18:18:10 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <lx0Q9LrQEu_whvnQMhC1het6OFoqnq8h527sD82ttYo=.f5e0d895-a103-46ec-8a5d-7c6d19d7417c@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <YK2EQtIP0-86eeLa1lOndwrMzuQ3uEh1VSIzmag1QrM=.21a33860-a201-48de-8be6-2b4c31fc5aa4@github.com>
 <lx0Q9LrQEu_whvnQMhC1het6OFoqnq8h527sD82ttYo=.f5e0d895-a103-46ec-8a5d-7c6d19d7417c@github.com>
Message-ID: <x8VwYy4Db0gGScpe62jb7CDp8vvv3W5veHda_W3i8hk=.6a184297-999a-41d2-a5eb-aafbcaaca10b@github.com>

On Thu, 30 Nov 2023 15:59:29 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320608
>
> test/jdk/java/awt/print/PageFormat/SmallPaperPrinting.java line 73:
> 
>> 71:           job.print();
>> 72:       }
>> 73:       catch (PrinterException e) {
> 
> Suggestion:
> 
>       } catch (PrinterException e) {
> 
> The `catch` keyword should be on the line with the closing brace of the `try {}` block.
> 
> It can be addressed in [JDK-8320671](https://bugs.openjdk.org/browse/JDK-8320671) when the test is updated.

fixed anyway

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411095104

From prr at openjdk.org  Thu Nov 30 18:23:28 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Nov 2023 18:23:28 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v3]
In-Reply-To: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
Message-ID: <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>

> Many printing tests do not have the @printer keyword. This adds them to those that need it.
> I also found one test that has nothing to do with printing in the print folder and moved it out.

Phil Race has updated the pull request incrementally with one additional commit since the last revision:

  8320608

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16785/files
  - new: https://git.openjdk.org/jdk/pull/16785/files/5fbc06d1..383f4532

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16785&range=01-02

  Stats: 7 lines in 4 files changed: 3 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16785.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16785/head:pull/16785

PR: https://git.openjdk.org/jdk/pull/16785

From prr at openjdk.org  Thu Nov 30 18:23:31 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Nov 2023 18:23:31 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v2]
In-Reply-To: <lx0Q9LrQEu_whvnQMhC1het6OFoqnq8h527sD82ttYo=.f5e0d895-a103-46ec-8a5d-7c6d19d7417c@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <YK2EQtIP0-86eeLa1lOndwrMzuQ3uEh1VSIzmag1QrM=.21a33860-a201-48de-8be6-2b4c31fc5aa4@github.com>
 <lx0Q9LrQEu_whvnQMhC1het6OFoqnq8h527sD82ttYo=.f5e0d895-a103-46ec-8a5d-7c6d19d7417c@github.com>
Message-ID: <bt2LSBlQ6xSvv2Uk2Dtgga8L3zvEBa6TvrwHrGOgO6I=.4e234ec1-fcbd-49d7-9414-05833acae1c5@github.com>

On Thu, 30 Nov 2023 17:08:21 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320608
>
> test/jdk/java/awt/print/PrinterJob/EmptyFill.java line 72:
> 
>> 70:            return;
>> 71:        }
>> 72:        PrinterJob pj = PrinterJob.getPrinterJob();
> 
> It looks good, however, I'd move the blank so that the code groups logically:
> 
> 
>        StreamPrintService svc = spfs[0].getPrintService(baos);
>        if (svc == null) {
>            return;
>        }
> 
>        PrinterJob pj = PrinterJob.getPrinterJob();
> 
> 
> Perhaps, the test should fail if `svc` happens to be `null`, after all it's quite unexpected if it's `null`, isn't it?

yes, it should always be possible to create the Postscript Stream PrintService - added throw new RTE.

> test/jdk/java/awt/print/PrinterJob/RemoveListener.java line 28:
> 
>> 26:  * @bug 4459889
>> 27:  * @summary No NullPointerException should occur.
>> 28:  * @key printer
> 
> Suggestion:
> 
>  * @test
>  * @bug 4459889
>  * @key printer
>  * @summary No NullPointerException should occur.
> 
> To be consistent with other tests.

fixed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411097828
PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411098415

From dnguyen at openjdk.org  Thu Nov 30 18:34:18 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 30 Nov 2023 18:34:18 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v3]
In-Reply-To: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
Message-ID: <j_fwoPLqmOT7ieaOiNEGvYFdHhUfDT1JW40iDZ8o1_Q=.0b155b54-95fe-422f-b1b2-498d72711537@github.com>

> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
> 
> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.

Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:

  Remove doc change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/16869/files
  - new: https://git.openjdk.org/jdk/pull/16869/files/b843a749..9b3e68cd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16869&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16869&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/16869.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16869/head:pull/16869

PR: https://git.openjdk.org/jdk/pull/16869

From dnguyen at openjdk.org  Thu Nov 30 18:34:21 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 30 Nov 2023 18:34:21 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v3]
In-Reply-To: <JHvSZzyhRbWZO1CltK-BlnflaTRsyur6U7usfEangeI=.3d729a73-192b-41e0-9959-0a467810551b@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <CQSziX92y40YHl3zE5z8_unyGQt3wsb3hVfOsK7sQ0c=.3f7d6354-63cf-4c6b-90c2-3ff56dce9807@github.com>
 <JHvSZzyhRbWZO1CltK-BlnflaTRsyur6U7usfEangeI=.3d729a73-192b-41e0-9959-0a467810551b@github.com>
Message-ID: <AdAku37pNzsb3TrutQ6yc2NEMF8nl7jq730gOkS0DW4=.d97aa443-4288-490a-9253-85a68dd61524@github.com>

On Wed, 29 Nov 2023 19:48:27 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/basic/BasicLookAndFeel.java line 464:
>> 
>>> 462:      * <p>
>>> 463:      * The default button margin value is (2, 14, 2, 14), which may
>>> 464:      * greatly differ from other LookAndFeel defaults.
>> 
>> This will need a CSR, which is fine.
>> But
>> (1) Basic is an abstract L&F .. it can't be the place to say what Metal does since most L&Fs derive from Basic
>> And something about a JButton ought to be closer to ButtonUI or JButton.
>> (2) Do we have precedent for calling out the exact number of (user space) pixels ?
>> I'd prefer some more waffly wording like 
>> "The default margins may vary greatly depending on the L&F".
>
> For (1), I've considered some alternative spots for this note. MetalButtonUI and MetalLookAndFeel for example, but I didn't see any natural spot to add this to. I decided to put it in BasicLookAndFeel since the default value is set here, but I see your point. I can add an additional note in the doc for, say, MetalButtonUI if preferred.
> 
> In (2), you're right that there's no explicit pixel count for anything. I'll update this to be more general. Do you think this additional note is enough to avoid adding more doc changes to Metal classes?

I have removed the doc change from this PR to focus mainly on fixing the regression first. Could you re-review when you get the chance?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16869#discussion_r1411110847

From prr at openjdk.org  Thu Nov 30 18:58:04 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Nov 2023 18:58:04 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <py0cj-EtumKfO-z3m3R-vqBmHdUNnOe5U26cHorCj2s=.e4f61400-6ae3-4bc9-ac22-8859691a612c@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <py0cj-EtumKfO-z3m3R-vqBmHdUNnOe5U26cHorCj2s=.e4f61400-6ae3-4bc9-ac22-8859691a612c@github.com>
Message-ID: <9qLcwHjtUaHzVXBQNm-_lr9EFgn4PIuhP4-os1euf0Q=.57039069-ff95-4257-9792-692482ca955d@github.com>

On Thu, 23 Nov 2023 13:21:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> @antbob Please trigger a test run of GHA. You should be able to do that in https://github.com/antbob/jdk/actions/workflows/main.yml (manual trigger). Thanks!

That is pointless for this change. There are ZERO tests that GHA runs that are related to client.

It will test that it builds, but nothing more.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16794#issuecomment-1834372659

From serb at openjdk.org  Thu Nov 30 19:23:08 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Nov 2023 19:23:08 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix
In-Reply-To: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
Message-ID: <Sx8xe-Twvv70czoEW4Y5N6Wjm2VXpxmu14_tPWm4LbY=.f6fa57fd-6419-4b83-bd3c-a0bcc1b50df8@github.com>

On Thu, 30 Nov 2023 03:34:08 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers, 
> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
> 
> Renjith.

Can this patch be covered by the new test?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1834408439

From sgehwolf at openjdk.org  Thu Nov 30 19:26:04 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 30 Nov 2023 19:26:04 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <9qLcwHjtUaHzVXBQNm-_lr9EFgn4PIuhP4-os1euf0Q=.57039069-ff95-4257-9792-692482ca955d@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <py0cj-EtumKfO-z3m3R-vqBmHdUNnOe5U26cHorCj2s=.e4f61400-6ae3-4bc9-ac22-8859691a612c@github.com>
 <9qLcwHjtUaHzVXBQNm-_lr9EFgn4PIuhP4-os1euf0Q=.57039069-ff95-4257-9792-692482ca955d@github.com>
Message-ID: <jocEc1sz2anJt-TQtuaw5ujgmCRacEegBmETQGPFb_0=.9f5eebd4-4791-4ea7-be3f-fb491f437c52@github.com>

On Thu, 30 Nov 2023 18:54:42 GMT, Phil Race <prr at openjdk.org> wrote:

> It will test that it builds, but nothing more.

Right, thanks. Still useful it's not breaking a build :) Besides, the settings carry forward for future PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/16794#issuecomment-1834411179

From serb at openjdk.org  Thu Nov 30 19:53:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Nov 2023 19:53:07 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v3]
In-Reply-To: <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>
Message-ID: <Mjm6WZ9gk3iy5-E8QIiNTvo2bLhIQfCPexpFwnp27JY=.6665e7ac-1813-4133-bd76-29d633cb17da@github.com>

On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320608

test/jdk/TEST.ROOT line 19:

> 17: # These keywords are there to help with test selection so that
> 18: # tests that need a particular resource can be selected to run on a system
> 19: # with that resource. Conversely "!somekeyword" can be used to exclude tests

probably we can link this from our wiki page where we describe the usage of keywords?:
https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements

BTW the "doc" has nothing related to printers right now as well:
https://github.com/openjdk/jdk/blob/master/doc/testing.md

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411189538

From serb at openjdk.org  Thu Nov 30 19:58:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Nov 2023 19:58:12 GMT
Subject: RFR: 8320349: Simplify FileChooserSymLinkTest.java by using
 single-window testUI
In-Reply-To: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
References: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
Message-ID: <NDelKTs8JAeqQwXIvqglye3TQlxN199pPPRcAuHzHXg=.f7b60b4b-0263-49cb-9dc1-e0959c93895f@github.com>

On Fri, 17 Nov 2023 20:21:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update `FileChooserSymLinkTest.java` to simplify its implementation by replacing `List<Window>` with `JFrame` of its `createTestUI` which now uses `PassFailJFrame.Builder testUI(PassFailJFrame.WindowCreator)` instead of `PassFailJFrame.Builder testUI(PassFailJFrame.WindowListCreator)`.
> 
> The test works correctly with and without the update.
> 
> This PR depends on #16717.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16718#pullrequestreview-1758334333

From serb at openjdk.org  Thu Nov 30 19:58:07 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Nov 2023 19:58:07 GMT
Subject: RFR: 8320303: Allow PassFailJFrame to accept single window creator
In-Reply-To: <j-rQt5NicpSozlOpkyvylyxN_r3FIBqLntXmmuvJ3e8=.85d33960-6e5e-4513-a6f3-fe283bbce43c@github.com>
References: <j-rQt5NicpSozlOpkyvylyxN_r3FIBqLntXmmuvJ3e8=.85d33960-6e5e-4513-a6f3-fe283bbce43c@github.com>
Message-ID: <nkX1RUwaQUHDmwNxL-BCQjm7BYTV3C_8x54kHDkxR8U=.8ebe6971-cb16-4c7b-bba1-6d6aa1bbbbdd@github.com>

On Fri, 17 Nov 2023 20:01:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Enhance `PassFailJFrame` for single-window test UI which is the most common case so that there's no need to return `List.of`.
> 
> With this change, the lambda or method reference passed to `Builder.testUI` will return Window instead of `List<Window>` (or `List<? extends Window>`.
> 
> This change adds new functional interface `WindowCreator` which returns a single Window; the existing interface is renamed to `WindowListCreator`.
> 
> It's backwards compatible change; the [FileChooserSymLinkTest.java](https://github.com/openjdk/jdk/blob/7f47c51aced9c724dbc9b0d8cbd88c49435da460/test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java) test which uses `Builder.testUI` works without change.
> 
> It was my main concern that it will be impossible to have two interfaces where one creates a `Windows` and another ? `List<Windows>`. The Java compiler automatically selects the correct method based on the return type of the lambda expression, so that both cases are supported. The requirement to return a `List` where only one window is needed bothered me, and I finally solved it.
> 
> In addition to that, I added description to all the overloads of the `Builder.testUI` method and updated the sample in the class documentation.
> 
> Since the `PassFailJFrame` class isn't supposed to be extended, I marked it `final` to prevent anyone from doing it.

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16717#pullrequestreview-1758335015

From prr at openjdk.org  Thu Nov 30 20:16:10 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Nov 2023 20:16:10 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v3]
In-Reply-To: <Mjm6WZ9gk3iy5-E8QIiNTvo2bLhIQfCPexpFwnp27JY=.6665e7ac-1813-4133-bd76-29d633cb17da@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>
 <Mjm6WZ9gk3iy5-E8QIiNTvo2bLhIQfCPexpFwnp27JY=.6665e7ac-1813-4133-bd76-29d633cb17da@github.com>
Message-ID: <N-kzr6W52Dn9mSvIyfX7LcTTEcWoy4Gdoj7ci8lCQ-0=.660b4320-f946-4c54-a6cc-5100c8fd3e8f@github.com>

On Thu, 30 Nov 2023 19:50:00 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> probably we can link this from our wiki page where we describe the usage of keywords?: https://wiki.openjdk.org/display/ClientLibs/Automated+client+GUI+testing+system+set+up+requirements


Good idea, once this is pushed, I'll add that right where we discuss the keywords. If I remember !

> 
> BTW the "doc" has nothing related to printers right now as well: https://github.com/openjdk/jdk/blob/master/doc/testing.md

Perhaps this is a bit too specialised to discuss there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411211838

From aivanov at openjdk.org  Thu Nov 30 20:38:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 20:38:13 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v3]
In-Reply-To: <jaqlZsvnTS9Mn1AQ0DWXjJIgW141P6kbAKgjp5BI3JM=.271036c4-d14d-42d4-ad43-9d1827e8fc9e@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <-89UjGPFJWRn0hJIyT5n2YLJKNCyaSeDPjOgw3dmZrw=.613b5081-039a-42cc-8b8c-f48fc91b9abd@github.com>
 <96ngNnlrygkt0Ni0W2xyr9STyYoQEALdDXtNu_jIQUg=.8969504d-ac54-4dc6-a271-08154523db94@github.com>
 <zOg35G9S05wsck3K-Ps2-g0wcFUQS8KekSmCjBY9oTE=.266b65ca-cb70-4cf6-be32-48ca332ef886@github.com>
 <gDO8hsy8vsBusp1HEut4bMarcgsiFCKeiR33e1MstC4=.57dc2b52-c799-480a-b01f-72396f24d440@github.com>
 <jaqlZsvnTS9Mn1AQ0DWXjJIgW141P6kbAKgjp5BI3JM=.271036c4-d14d-42d4-ad43-9d1827e8fc9e@github.com>
Message-ID: <lBFP1Q7WXEbCPMX71EKJLfshXbnp6X02iLUimqW1u_g=.8e6103b5-ca9f-446f-90e2-b72b96e0be8d@github.com>

On Thu, 30 Nov 2023 18:14:21 GMT, Phil Race <prr at openjdk.org> wrote:

>> That's the reason why I prefer you keep the `@run` tag in `SetOrient.java`: to document that it's *an applet test* ? with the html file being the test starter.
>
> Ok, although when I see something like that it looks more like a bug to me.

It's an applet, it should be re-written as a standalone app. I'll submit a bug for it, if I don't forget. It could be picked up by an external contributor?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16785#discussion_r1411231060

From serb at openjdk.org  Thu Nov 30 20:38:11 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 30 Nov 2023 20:38:11 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v3]
In-Reply-To: <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>
Message-ID: <LSmF_ZeP42StGqSCsXFey2nrcFbNbsIvH03Ah4l1rjw=.5db590d7-f5e8-4eb3-9d45-dc90e7e7cc49@github.com>

On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320608

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1758403498

From aivanov at openjdk.org  Thu Nov 30 20:42:10 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 30 Nov 2023 20:42:10 GMT
Subject: RFR: 8320608: Many jtreg printing tests are missing the @printer
 keyword [v3]
In-Reply-To: <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
 <DwHnHSgBLNZhiVrx0bBRvFVV9VBu1Dh4pd_36YGF4ks=.041757d8-e5b6-4fd2-b8b2-45336d5f6c6e@github.com>
Message-ID: <t7KBG8KCYAOkpnp03RDjIizP9dM1D6ZW2zaBTfbdBRU=.bd51aa33-8ef2-4aaf-8aad-d0ec9c8dcb51@github.com>

On Thu, 30 Nov 2023 18:23:28 GMT, Phil Race <prr at openjdk.org> wrote:

>> Many printing tests do not have the @printer keyword. This adds them to those that need it.
>> I also found one test that has nothing to do with printing in the print folder and moved it out.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320608

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/16785#pullrequestreview-1758414252

From azvegint at openjdk.org  Thu Nov 30 21:47:07 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 30 Nov 2023 21:47:07 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
Message-ID: <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>

On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 930:

> 928:             fp_pw_thread_loop_unlock(pw.loop);
> 929:             releaseToken(env, jtoken, token);
> 930:             return RESULT_ERROR;

I think that the fix can be improved a bit.
Right now it just gives a black image on failure. We can try to add another attempt to get the image we need.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1411292492

From prr at openjdk.org  Thu Nov 30 23:02:17 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 30 Nov 2023 23:02:17 GMT
Subject: Integrated: 8320608: Many jtreg printing tests are missing the
 @printer keyword
In-Reply-To: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
References: <qcrxgc1W0V0JOMOnjpTe02RaOCa_iJlWQdq5y9re5YU=.54e6a96a-6b5a-40af-a573-60a447ecc647@github.com>
Message-ID: <VcYXOJ0hTC-vATHPWVLylQ0qBIbP8hbtX1jm5mGvnFk=.87b705af-11bd-40d5-af96-912dc4d63ecb@github.com>

On Wed, 22 Nov 2023 19:26:40 GMT, Phil Race <prr at openjdk.org> wrote:

> Many printing tests do not have the @printer keyword. This adds them to those that need it.
> I also found one test that has nothing to do with printing in the print folder and moved it out.

This pull request has now been integrated.

Changeset: 76fea807
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/76fea807071eee80a1e00aae7bc4784a6d35bf4b
Stats:     247 lines in 139 files changed: 140 ins; 23 del; 84 mod

8320608: Many jtreg printing tests are missing the @printer keyword

Reviewed-by: aivanov, serb

-------------

PR: https://git.openjdk.org/jdk/pull/16785