From rkannathpari at openjdk.org  Mon Apr  1 05:11:49 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 1 Apr 2024 05:11:49 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v14]
In-Reply-To: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
Message-ID: <X9V6UPEt5R1peCVCpyvY5sjZFZK5MORHOZGpIPp_B3c=.3605c5b4-00f8-4674-95b5-7b420bbd81e9@github.com>

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Updated PassFailJFrame object creation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17607/files
  - new: https://git.openjdk.org/jdk/pull/17607/files/892be4a0..a3d2a6d4

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

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

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

From rkannathpari at openjdk.org  Mon Apr  1 05:38:54 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 1 Apr 2024 05:38:54 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v15]
In-Reply-To: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
Message-ID: <UjyKUWJu0ZuUx6a1bZdn8v9mmfKPtrocxHm-nw358FQ=.23894605-c737-44d9-a1c8-6c9bdc008b15@github.com>

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Optimized switch case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17607/files
  - new: https://git.openjdk.org/jdk/pull/17607/files/a3d2a6d4..cd8d67dd

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

  Stats: 27 lines in 1 file changed: 10 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/17607.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17607/head:pull/17607

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

From achung at openjdk.org  Mon Apr  1 06:23:35 2024
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 1 Apr 2024 06:23:35 GMT
Subject: RFR: 8328648: Remove applet usage from JFileChooser tests
 bug4150029 [v8]
In-Reply-To: <vSQO8SIfI94EJ_WEUt5cAF3GAAQBhEyJncc_37F5Xbs=.7b7d7edd-4473-47bc-ab3b-5d418f40c7fa@github.com>
References: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
 <ge37OFMCxfobhjv-bD-nYyM3C_AWx28kPXF2_4qXL7M=.5e2a7ad0-01b0-4c07-b106-6ddbd9bafa00@github.com>
 <vSQO8SIfI94EJ_WEUt5cAF3GAAQBhEyJncc_37F5Xbs=.7b7d7edd-4473-47bc-ab3b-5d418f40c7fa@github.com>
Message-ID: <9uI_ZRwaakOYXJ7oSbRM3nx017UJn2ILKqpQiYKyFPI=.c5d9f19a-ba6b-41b0-a939-405bcc7024bd@github.com>

On Fri, 29 Mar 2024 16:43:53 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Looks good now. Only point is "should we move this test outside folder as html file is deleted now?". Hope you have tested in CI for all platform.

Clientlibs is green, also I'll keep this inside the folder for bookkeeping

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

PR Comment: https://git.openjdk.org/jdk/pull/18415#issuecomment-2029234162

From achung at openjdk.org  Mon Apr  1 06:24:42 2024
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 1 Apr 2024 06:24:42 GMT
Subject: Integrated: 8328403: Remove applet usage from JColorChooser tests
 Test6977726
In-Reply-To: <pyfxVdApSNSisMJieBTl5HSZKDmSSiPie0tnrM_rwe4=.5ffc4e92-cbcf-44d8-9a51-b4e8330e1be9@github.com>
References: <pyfxVdApSNSisMJieBTl5HSZKDmSSiPie0tnrM_rwe4=.5ffc4e92-cbcf-44d8-9a51-b4e8330e1be9@github.com>
Message-ID: <8qC2FGw9YxD--ivRdrMut8ArE5PXe1NG8QdHrjTbUdU=.04d8b9ba-5131-4aab-82b5-6ec384c7bebb@github.com>

On Tue, 19 Mar 2024 01:47:01 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removing applet usage from manual JColorChooser tests

This pull request has now been integrated.

Changeset: 1e76e1fd
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e76e1fdfa67c28ce20b0dc7fb0253670be54554
Stats:     63 lines in 2 files changed: 21 ins; 32 del; 10 mod

8328403: Remove applet usage from JColorChooser tests Test6977726

Reviewed-by: tr, honkar

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

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

From rkannathpari at openjdk.org  Mon Apr  1 06:34:49 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 1 Apr 2024 06:34:49 GMT
Subject: RFR: 8324807 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 2 [v14]
In-Reply-To: <UZ9jtQbkj-MoeLoccJnd2_3ciCCy9n-CD5vDv0hVKME=.f67db96d-92e6-46a1-9bb6-4fe77c9a8c4e@github.com>
References: <UZ9jtQbkj-MoeLoccJnd2_3ciCCy9n-CD5vDv0hVKME=.f67db96d-92e6-46a1-9bb6-4fe77c9a8c4e@github.com>
Message-ID: <X6V45_rBk_h5XI8N3Dh-tFNpG7Eq7yAqfXHxZntGZS0=.7c504ec1-16f2-43fe-9077-da573ff286f6@github.com>

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Suggestions integrated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17608/files
  - new: https://git.openjdk.org/jdk/pull/17608/files/aa801855..0243809f

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

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

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

From abhiscxk at openjdk.org  Mon Apr  1 07:19:34 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 1 Apr 2024 07:19:34 GMT
Subject: RFR: 8328648: Remove applet usage from JFileChooser tests
 bug4150029 [v8]
In-Reply-To: <ge37OFMCxfobhjv-bD-nYyM3C_AWx28kPXF2_4qXL7M=.5e2a7ad0-01b0-4c07-b106-6ddbd9bafa00@github.com>
References: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
 <ge37OFMCxfobhjv-bD-nYyM3C_AWx28kPXF2_4qXL7M=.5e2a7ad0-01b0-4c07-b106-6ddbd9bafa00@github.com>
Message-ID: <IYyI3pN8UHFwlcroBT_T9hy_jVu3xMLSeNLvO1NaLhE=.11f73cbe-7b46-4f8f-af81-ee56b76e36b7@github.com>

On Fri, 29 Mar 2024 14:37:42 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removing applet usage from manual JFileChooser tests
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move var into local, simplified condition check, spacing

> /integrate

You need a "Reviewer" approval to integrate.

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

PR Comment: https://git.openjdk.org/jdk/pull/18415#issuecomment-2029293976

From psadhukhan at openjdk.org  Mon Apr  1 09:07:58 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Apr 2024 09:07:58 GMT
Subject: RFR: 8328541: Remove or update obsolete comment in JRootPane [v2]
In-Reply-To: <qrXxd1TMO9n9ee6mml-H0hMTnCxpO2zb4gL5xsr76Tg=.75cdb5ba-9b1d-4bee-a592-2521f90aacd4@github.com>
References: <qrXxd1TMO9n9ee6mml-H0hMTnCxpO2zb4gL5xsr76Tg=.75cdb5ba-9b1d-4bee-a592-2521f90aacd4@github.com>
Message-ID: <8NcdNxQrmYq4wUb3S9xh9wj-sfXjIic6U-ax0f3al1M=.93643d30-adfe-4c80-9887-917104db6cef@github.com>

> There is an old obsolete comment in JRootPane that is between the main documentation comment for the class and the declaration of the class itself which is  causing interference with the work to support Markdown in documentation comments using the `///` style of comment. (JEP 467) so removing this comment..

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

  copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18545/files
  - new: https://git.openjdk.org/jdk/pull/18545/files/c62ba8a7..051cd70e

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

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

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

From jwaters at openjdk.org  Mon Apr  1 10:36:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 1 Apr 2024 10:36:54 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v49]
In-Reply-To: <AzYAekHLwY_K386KelWcqVFxNjUytdTUhL80PYQ2Mjc=.808d5bf0-d33b-4cba-9f04-9f64b1b7819c@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <yG7ympQmG-rP5X6IFYGcxQygtaA-xzNkPt59f6dUt1c=.176ac703-a8f9-4901-8cc4-f7580567786c@github.com>
 <Sa7q7l1nNcZeLvLpe7G_-8fvnhukSf8UZolZ3QIoVxc=.f864754a-b733-46e7-b215-e2fe9de32c80@github.com>
 <AzYAekHLwY_K386KelWcqVFxNjUytdTUhL80PYQ2Mjc=.808d5bf0-d33b-4cba-9f04-9f64b1b7819c@github.com>
Message-ID: <N4VjxDmSkXLYG8HecwI8TElcE-GcE0Utxa5kd5S0grE=.bc0b48e2-0307-465d-9e03-de7239f94f89@github.com>

On Sun, 21 Jan 2024 19:50:16 GMT, Phil Race <prr at openjdk.org> wrote:

>> Fixed the formatting (at least in the marked cases), but am unsure what you mean by set directly?
>
>> Fixed the formatting (at least in the marked cases), but am unsure what you mean by set directly?
> 
> See my comment 
> "like in my recoded case above, we no longer need the "pData" var which was there only because that name
> is magically known to the macro."
> 
> so skip (and get rid of) the pData var and just set the target var directly

I've switched the marked cases to use direct setting and bypass pData, should I do the unmarked ones too? @prrace

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

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

From jwaters at openjdk.org  Mon Apr  1 10:36:54 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 1 Apr 2024 10:36:54 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v70]
In-Reply-To: <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
Message-ID: <H8DdyOjIYbpj5JxJDTW0-t92A9aUnY1Bquz02XWgFEk=.53238f29-59cf-4bfa-a131-cde8eae1d662@github.com>

On Thu, 28 Mar 2024 07:36:04 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 four additional commits since the last revision:
> 
>  - Labels to empty line in awt_Window.cpp
>  - Labels to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp

Bumping

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

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

From psadhukhan at openjdk.org  Mon Apr  1 13:01:37 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 1 Apr 2024 13:01:37 GMT
Subject: Integrated: 8328541: Remove or update obsolete comment in JRootPane
In-Reply-To: <qrXxd1TMO9n9ee6mml-H0hMTnCxpO2zb4gL5xsr76Tg=.75cdb5ba-9b1d-4bee-a592-2521f90aacd4@github.com>
References: <qrXxd1TMO9n9ee6mml-H0hMTnCxpO2zb4gL5xsr76Tg=.75cdb5ba-9b1d-4bee-a592-2521f90aacd4@github.com>
Message-ID: <39lD3n71fUdkzHQYKKscXkXUBRqzhS3-eDnEwvD-y5I=.e6a18721-2104-4cb7-9a28-d0484376db16@github.com>

On Fri, 29 Mar 2024 07:21:17 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> There is an old obsolete comment in JRootPane that is between the main documentation comment for the class and the declaration of the class itself which is  causing interference with the work to support Markdown in documentation comments using the `///` style of comment. (JEP 467) so removing this comment..

This pull request has now been integrated.

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

8328541: Remove or update obsolete comment in JRootPane

Reviewed-by: aivanov, abhiscxk

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

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

From manc at openjdk.org  Mon Apr  1 18:27:17 2024
From: manc at openjdk.org (Man Cao)
Date: Mon, 1 Apr 2024 18:27:17 GMT
Subject: RFR: 8329352: Remove dead code in splashscreen_sys.c [v3]
In-Reply-To: <xe-wpIn8dHrfbjI1ZlHq4ad_s4UHnH7_ZDPB1kucFrM=.8a0a0d84-683c-40cc-ace1-e887abd58a10@github.com>
References: <xe-wpIn8dHrfbjI1ZlHq4ad_s4UHnH7_ZDPB1kucFrM=.8a0a0d84-683c-40cc-ace1-e887abd58a10@github.com>
Message-ID: <x6pM0RsRh5dc2LUMTXTzCF0jSBsrbiAJHXdIV9TpCHQ=.542e57f1-6381-42e9-9e60-5c87780b8fb4@github.com>

> Hi all,
> 
> Could anyone review this trivial change to remove dead code in splashscreen_sys.c?
> 
> -Man

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

  Remove XSetIOErrorHandler() and irrelevant comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18556/files
  - new: https://git.openjdk.org/jdk/pull/18556/files/6b555e96..f7218541

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

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

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

From manc at openjdk.org  Mon Apr  1 18:27:17 2024
From: manc at openjdk.org (Man Cao)
Date: Mon, 1 Apr 2024 18:27:17 GMT
Subject: RFR: 8329352: Remove dead code in splashscreen_sys.c [v2]
In-Reply-To: <TErSg_m1aDEkFPx8cpVfRiKR4UfXtYboWGRunwpA_Jw=.2cacb5f4-3247-4244-a1c5-cb912a19b1fc@github.com>
References: <xe-wpIn8dHrfbjI1ZlHq4ad_s4UHnH7_ZDPB1kucFrM=.8a0a0d84-683c-40cc-ace1-e887abd58a10@github.com>
 <UZDPXj4KPtZu2kqxDLNuQmwqiMkFU3jHG-RRba3v-2E=.d2fdd452-dd88-4940-8226-f0ffd6ebeed3@github.com>
 <TErSg_m1aDEkFPx8cpVfRiKR4UfXtYboWGRunwpA_Jw=.2cacb5f4-3247-4244-a1c5-cb912a19b1fc@github.com>
Message-ID: <7d2IdC8o-LqAooj73nZfqyGyL-CIy2hd7TqEl8gJkxc=.cde00ecc-8147-4db4-81f0-3ba222bd2fe8@github.com>

On Sat, 30 Mar 2024 21:17:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year
>
> src/java.desktop/unix/native/libsplashscreen/splashscreen_sys.c line 393:
> 
>> 391:     pthread_mutex_init(&splash->lock, NULL);
>> 392: 
>> 393:     // We should not ignore any errors.
> 
> The 2nd commented out call looks like it might have been doing something better than the default handler,
> but not by so much as to matter. 
> The comment seems a bit inappropriate now and I'm puzzled why we need to reinstall the default handler
> (ie the call taking NULL), since we haven't installed a non-default handler anyway.
> I'd be inclined to remove the comment and the call.

Thanks. Makes sense, removed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18556#discussion_r1546676556

From dnguyen at openjdk.org  Mon Apr  1 19:33:00 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 1 Apr 2024 19:33:00 GMT
Subject: RFR: 8328648: Remove applet usage from JFileChooser tests
 bug4150029 [v8]
In-Reply-To: <ge37OFMCxfobhjv-bD-nYyM3C_AWx28kPXF2_4qXL7M=.5e2a7ad0-01b0-4c07-b106-6ddbd9bafa00@github.com>
References: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
 <ge37OFMCxfobhjv-bD-nYyM3C_AWx28kPXF2_4qXL7M=.5e2a7ad0-01b0-4c07-b106-6ddbd9bafa00@github.com>
Message-ID: <f7FDAyE14XcFuN43XKuKAk2rnjnfBTsdcq44VwX7_g8=.64604a9b-565e-4b55-9e1a-a38fde8a34af@github.com>

On Fri, 29 Mar 2024 14:37:42 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removing applet usage from manual JFileChooser tests
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move var into local, simplified condition check, spacing

Agreed. Looks good now, especially if CI is green. Still need "R"eviewer approval.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18415#pullrequestreview-1971977772

From ihse at openjdk.org  Mon Apr  1 20:32:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 1 Apr 2024 20:32:26 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v70]
In-Reply-To: <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
Message-ID: <XOwjZf7g4_euX81jZNzSUAQg_dS_SOYkGrj8WsN8Mos=.72ebf892-b347-4334-bca2-7f46b99e2bb1@github.com>

On Thu, 28 Mar 2024 07:36:04 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 four additional commits since the last revision:
> 
>  - Labels to empty line in awt_Window.cpp
>  - Labels to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp

Yes, fix all pData in areas touched by your changes.

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

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

From honkar at openjdk.org  Mon Apr  1 21:02:02 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 1 Apr 2024 21:02:02 GMT
Subject: RFR: 8328648: Remove applet usage from JFileChooser tests
 bug4150029 [v8]
In-Reply-To: <ge37OFMCxfobhjv-bD-nYyM3C_AWx28kPXF2_4qXL7M=.5e2a7ad0-01b0-4c07-b106-6ddbd9bafa00@github.com>
References: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
 <ge37OFMCxfobhjv-bD-nYyM3C_AWx28kPXF2_4qXL7M=.5e2a7ad0-01b0-4c07-b106-6ddbd9bafa00@github.com>
Message-ID: <0_6FCyB68Dhyi8-iKjQBFXRrxES-87rUjODLWdJ8bCE=.99196c09-bc57-400a-8a87-308a0d25e9b7@github.com>

On Fri, 29 Mar 2024 14:37:42 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removing applet usage from manual JFileChooser tests
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move var into local, simplified condition check, spacing

Changes requested by honkar (Reviewer).

test/jdk/javax/swing/JFileChooser/4150029/bug4150029.java line 126:

> 124:         clickBackSpace();
> 125: 
> 126:         if (prevDir == crntDir) {

Wrong comparison operator, it should be .equals() here. 
You might want to run the CI testing again with the updated changes just to make sure it works the same on all platforms.

Suggestion:

        if (prevDir.equals(crntDir)) {

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

PR Review: https://git.openjdk.org/jdk/pull/18415#pullrequestreview-1972107056
PR Review Comment: https://git.openjdk.org/jdk/pull/18415#discussion_r1546837460

From honkar at openjdk.org  Mon Apr  1 21:32:04 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 1 Apr 2024 21:32:04 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v4]
In-Reply-To: <QNyJ-3Z_mL-93xX-i9M_dfRv68fJ3NXKqz0uCvD6v5I=.38160411-9cec-469a-8de8-ad6c0ceb38c8@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <QNyJ-3Z_mL-93xX-i9M_dfRv68fJ3NXKqz0uCvD6v5I=.38160411-9cec-469a-8de8-ad6c0ceb38c8@github.com>
Message-ID: <CvY9IP_u5ooinIHxAGmC03VnJYWnRemIqOMQwGr0i3E=.e1cebff7-2429-4464-8dee-92c3c016145b@github.com>

On Thu, 22 Feb 2024 06:35:19 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> 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 requested by honkar (Reviewer).

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 72:

> 70: 
> 71:     public static void main(String[] args) throws Exception {
> 72:         PassFailJFrame passFailJFrame = new PassFailJFrame.Builder()

Test needs to be updated as per the new PassFailJFrame builder changes. 

`PassFailJFrame.builder()`

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

PR Review: https://git.openjdk.org/jdk/pull/17720#pullrequestreview-1972154155
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1546866413

From dcubed at openjdk.org  Mon Apr  1 22:19:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 22:19:06 GMT
Subject: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on
 linux-x64
Message-ID: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>

Trivial fixes to ProblemList noisy tests:

[JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
[JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
[JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
[JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

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

Commit messages:
 - 8329428: ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp
 - 8329427: ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
 - 8329426: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
 - 8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64

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

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

From dholmes at openjdk.org  Mon Apr  1 22:19:07 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 1 Apr 2024 22:19:07 GMT
Subject: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on
 linux-x64
In-Reply-To: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
References: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
Message-ID: <q-Mr1JtFWiWhBUaGPaM8BCop8Rln9up-Sq5IR4iwyag=.f689662f-aa4c-47c1-9ce8-73dd756ebc9c@github.com>

On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList noisy tests:
> 
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
> [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
> [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

Seems okay. Thanks

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18568#pullrequestreview-1972236395

From dcubed at openjdk.org  Mon Apr  1 22:25:07 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 22:25:07 GMT
Subject: Integrated: 8329425: ProblemList containers/docker/TestJFREvents.java
 on linux-x64
In-Reply-To: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
References: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
Message-ID: <9d0JDigfqBMaHdGS17bfqOTt0bCI4k474KSe4GcfXdU=.cc7c5d99-e1b7-417c-9bfd-a6142a571800@github.com>

On Mon, 1 Apr 2024 21:07:34 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList noisy tests:
> 
> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
> [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
> [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

This pull request has now been integrated.

Changeset: c2979c15
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c2979c150bdbcc2a9e6026347dc590e6a7e86595
Stats:     5 lines in 3 files changed: 4 ins; 0 del; 1 mod

8329425: ProblemList containers/docker/TestJFREvents.java on linux-x64
8329426: ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
8329427: ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
8329428: ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp

Reviewed-by: dholmes

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

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

From dcubed at openjdk.org  Mon Apr  1 22:25:06 2024
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Mon, 1 Apr 2024 22:25:06 GMT
Subject: RFR: 8329425: ProblemList containers/docker/TestJFREvents.java on
 linux-x64
In-Reply-To: <q-Mr1JtFWiWhBUaGPaM8BCop8Rln9up-Sq5IR4iwyag=.f689662f-aa4c-47c1-9ce8-73dd756ebc9c@github.com>
References: <4IV494kBFp8o93ikOFJEWQMsXtWXfh4EsThZ8fSIsKE=.c6d109e4-d1a4-4140-9ad7-96e6cbaa6eb1@github.com>
 <q-Mr1JtFWiWhBUaGPaM8BCop8Rln9up-Sq5IR4iwyag=.f689662f-aa4c-47c1-9ce8-73dd756ebc9c@github.com>
Message-ID: <ktN8Vs7ylk1iJ7204chIi0srcHl_3S-TdurRe2eRsSQ=.28127285-761b-49f9-9816-d979167d781b@github.com>

On Mon, 1 Apr 2024 22:15:06 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Trivial fixes to ProblemList noisy tests:
>> 
>> [JDK-8329425](https://bugs.openjdk.org/browse/JDK-8329425) ProblemList containers/docker/TestJFREvents.java on linux-x64
>> [JDK-8329426](https://bugs.openjdk.org/browse/JDK-8329426) ProblemList vmTestbase/nsk/jvmti/scenarios/capability/CM03/cm03t001/TestDescription.java with Xcomp on windows-x64
>> [JDK-8329427](https://bugs.openjdk.org/browse/JDK-8329427) ProblemList javax/sound/sampled/Clip/ClipFlushCrash.java on linux-x64
>> [JDK-8329428](https://bugs.openjdk.org/browse/JDK-8329428) ProblemList vmTestbase/nsk/stress/thread/thread006.java on linux-all in Xcomp
>
> Seems okay. Thanks

@dholmes-ora - Thanks for the lightning fast review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18568#issuecomment-2030672631

From duke at openjdk.org  Mon Apr  1 22:58:08 2024
From: duke at openjdk.org (Larry Cable)
Date: Mon, 1 Apr 2024 22:58:08 GMT
Subject: RFR: 8321428: Deprecate for removal the package java.beans.beancontext
Message-ID: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>

the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.

based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".

This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.

This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

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

Commit messages:
 - 8321428: Deprecate for removal the package java.beans.beancontext

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

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

From prr at openjdk.org  Tue Apr  2 04:19:00 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:19:00 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext
In-Reply-To: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
Message-ID: <N5Qk29aR4HgHXSgw7pniX8XVE8lw5qoUXAh3LtWX2Wc=.03434663-2cd2-43b2-b113-fbbd2c41f09e@github.com>

On Mon, 1 Apr 2024 22:53:12 GMT, Larry Cable <duke at openjdk.org> wrote:

> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
> 
> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
> 
> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
> 
> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18569#pullrequestreview-1972575672

From prr at openjdk.org  Tue Apr  2 04:27:18 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:27:18 GMT
Subject: RFR: 8329320: Simplify awt/print/PageFormat/NullPaper.java test
In-Reply-To: <0CQ06Dw6Uwa9Z2lLfqFhdAWxWVLiYJs-EoziVLODxlw=.0133d820-1a13-4813-bc20-c9358fcbc58c@github.com>
References: <0CQ06Dw6Uwa9Z2lLfqFhdAWxWVLiYJs-EoziVLODxlw=.0133d820-1a13-4813-bc20-c9358fcbc58c@github.com>
Message-ID: <pAwOd6pYi6DFpv5rS009YauNGBBYM3UvRhw_Z2nfZAc=.5a851cc2-c540-471c-ae1b-f0800452e14f@github.com>

On Fri, 29 Mar 2024 12:45:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove all the leftovers of the _"standard instructions" machinery_ from the `NullPaper.java` test.
> 
> The test code consists of two lines now: concise and clear.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18547#pullrequestreview-1972579654

From prr at openjdk.org  Tue Apr  2 04:27:20 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:27:20 GMT
Subject: RFR: 8329340: Remove unused libawt code
In-Reply-To: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
Message-ID: <jRIJ-_yTZNrhNQPVLS6dTOp3Q2l3_I-r22IzU39AMbE=.c7acba58-f53a-4b5f-8bf5-e56e8aaa5b1b@github.com>

On Fri, 29 Mar 2024 18:23:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
> 
> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
> 
> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.

Good to push this early in the week in case the testing was some how not enough.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18553#pullrequestreview-1972579228

From prr at openjdk.org  Tue Apr  2 04:28:22 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:28:22 GMT
Subject: RFR: JDK-8328753 : Open source few Undecorated Frame tests [v3]
In-Reply-To: <erA5EWbQxnZGfvc5qdQ5N1jT1wgrAIvQu8n-K_yiqzU=.07148e01-3211-4d6b-b50e-a745fe5e27a5@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
 <erA5EWbQxnZGfvc5qdQ5N1jT1wgrAIvQu8n-K_yiqzU=.07148e01-3211-4d6b-b50e-a745fe5e27a5@github.com>
Message-ID: <gyU6RPq9sYd5KvdvTn8Vwr8-_pGv8bjVPmCytTdzcVA=.2198d717-300f-40ab-a786-8872e669f67e@github.com>

On Fri, 29 Mar 2024 17:29:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Following tests are converted to main and open-sourced:
>> 
>> - /java/awt/Frame/FrameDialogMixedTest.java- Converted to main/manual using PassFailJFrame.
>> - /java/awt/Frame/MaximizeUndecoratedTest.java - Automated
>> - /java/awt/Frame/MinimizeUndecoratedTest.java - Automated
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RuntimeException thrown

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18523#pullrequestreview-1972582376

From prr at openjdk.org  Tue Apr  2 04:31:00 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:31:00 GMT
Subject: RFR: 8329352: Remove dead code in splashscreen_sys.c [v3]
In-Reply-To: <x6pM0RsRh5dc2LUMTXTzCF0jSBsrbiAJHXdIV9TpCHQ=.542e57f1-6381-42e9-9e60-5c87780b8fb4@github.com>
References: <xe-wpIn8dHrfbjI1ZlHq4ad_s4UHnH7_ZDPB1kucFrM=.8a0a0d84-683c-40cc-ace1-e887abd58a10@github.com>
 <x6pM0RsRh5dc2LUMTXTzCF0jSBsrbiAJHXdIV9TpCHQ=.542e57f1-6381-42e9-9e60-5c87780b8fb4@github.com>
Message-ID: <GSDvZ--19yBB67yMc4xQ5zTGqDoYk3LFDIPNfCP7c3E=.41483dfc-7aaf-45c4-9e75-18ae1db944a3@github.com>

On Mon, 1 Apr 2024 18:27:17 GMT, Man Cao <manc at openjdk.org> wrote:

>> Hi all,
>> 
>> Could anyone review this trivial change to remove dead code in splashscreen_sys.c?
>> 
>> -Man
>
> Man Cao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove XSetIOErrorHandler() and irrelevant comment

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18556#pullrequestreview-1972583826

From prr at openjdk.org  Tue Apr  2 04:32:03 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:32:03 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
Message-ID: <NgBnKud1Uq87DLBueWfPg2kvS14XcjTRvcrskLYa_f8=.3d857505-1a9d-41a9-936d-6763f7a4d630@github.com>

On Fri, 29 Mar 2024 09:49:54 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Convert and open source these manual applet test to main based:
>> java/awt/Frame/MegaIconTest/MegaIconTest.html
>> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
>> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
>> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
>> 
>> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reveiw updates and SizeMinimizedTest converted to auto test

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18448#pullrequestreview-1972583458

From prr at openjdk.org  Tue Apr  2 04:32:06 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:32:06 GMT
Subject: Integrated: 8328561: test
 java/awt/Robot/ManualInstructions/ManualInstructions.java isn't used
In-Reply-To: <ABW2Bldb5eN2as1Jb7G7lFW1ULTIizQwTaHQTORhLnc=.02516bdc-9b01-4748-b80e-fa54b0b8996e@github.com>
References: <ABW2Bldb5eN2as1Jb7G7lFW1ULTIizQwTaHQTORhLnc=.02516bdc-9b01-4748-b80e-fa54b0b8996e@github.com>
Message-ID: <BKgdW82IG5VIUb53WKGPon7V7Q9f-rOcb1M9yCFSTd8=.2b0ba170-7149-49af-a435-133012ec8265@github.com>

On Thu, 21 Mar 2024 20:00:48 GMT, Phil Race <prr at openjdk.org> wrote:

> I don't know why this file is checked in. It has no @test tag and doesn't do anything. I am deleting it.

This pull request has now been integrated.

Changeset: bc546c21
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bc546c21a59d2481ba86f98d0d653c7691f68d4c
Stats:     328 lines in 1 file changed: 0 ins; 328 del; 0 mod

8328561: test java/awt/Robot/ManualInstructions/ManualInstructions.java isn't used

Reviewed-by: dnguyen, psadhukhan

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

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

From tr at openjdk.org  Tue Apr  2 04:32:06 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Apr 2024 04:32:06 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <58u8WoxBOGloYA7EXLkn3VtW1do4EFn8Yt5rgMAYjX0=.ebf40f6e-846b-4302-aea2-d8c8a7a6821b@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
 <58u8WoxBOGloYA7EXLkn3VtW1do4EFn8Yt5rgMAYjX0=.ebf40f6e-846b-4302-aea2-d8c8a7a6821b@github.com>
Message-ID: <Bt1ChmFSOUQ8mP6CwD2xaRRyRAWqO9t3PJ7OkCvO8BU=.2a727cf7-6d9c-4115-860f-28ad2ba5b589@github.com>

On Fri, 29 Mar 2024 17:58:59 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reveiw updates and SizeMinimizedTest converted to auto test
>
> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 39:
> 
>> 37:  * @key headful
>> 38:  * @bug 4065534
>> 39:  * @summary Frame.setSize() doesn't change size if window is in an iconified state
> 
> The main objective of the original test is missing with the current updated test. The test is to check whether Frame.setSize() works when Frame is in iconified state. Currently the test checks frame size and location when in Normal state.

I don't see it either in original and customer submitted test too. The test checks for frame size and location in normal state.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1547119898

From rkannathpari at openjdk.org  Tue Apr  2 04:33:05 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 2 Apr 2024 04:33:05 GMT
Subject: Integrated: 8324808 : Manual printer tests have no Pass/Fail buttons, 
 instructions close set 3
In-Reply-To: <BFuAfPibaBpToXKzPNGUKf6pC1DvjrAedYHdtJxtuO8=.d54fcf6c-0727-4a4e-8a94-73a4ebe78af4@github.com>
References: <BFuAfPibaBpToXKzPNGUKf6pC1DvjrAedYHdtJxtuO8=.d54fcf6c-0727-4a4e-8a94-73a4ebe78af4@github.com>
Message-ID: <0UCOkft7p3zylzrPNSojykVSWaBqN1zgPyxJls_bfJs=.4ee73401-536b-4332-ab1e-2f8ef9c2592a@github.com>

On Mon, 29 Jan 2024 07:22:57 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

This pull request has now been integrated.

Changeset: af7c6af0
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/af7c6af0cc1eb6c42199c05933c7feb032bd6353
Stats:     1638 lines in 6 files changed: 296 ins; 1069 del; 273 mod

8324808: Manual printer tests have no Pass/Fail buttons, instructions close set 3

Reviewed-by: tr, achung, aivanov

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

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

From prr at openjdk.org  Tue Apr  2 04:38:27 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 2 Apr 2024 04:38:27 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v70]
In-Reply-To: <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
Message-ID: <sxi7OQ9Q3qjq0W-e54D3j4f8eIi7uemktrJTT63O_xI=.b961c114-5bc8-4015-a641-6a83a36be3c4@github.com>

On Thu, 28 Mar 2024 07:36:04 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 four additional commits since the last revision:
> 
>  - Labels to empty line in awt_Window.cpp
>  - Labels to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp

I've been monitoring it but saw no reason to pay particular attention until everything I raised is addressed.
Including the cases identical to the ones I explicitly identified
(which I suppose is what is meant by your question "should I do the unmarked ones too ?").
At some point you do tire of typing "ditto" :-)

It has been long enough that I will need a little time to remember and re-review properly once the requested changes are in place.

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

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

From tr at openjdk.org  Tue Apr  2 04:45:01 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Apr 2024 04:45:01 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
 <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
Message-ID: <2znFUyrPWkaar5hi-PzW4zlAVJJKoTm6ICbbfbqE254=.adbce20c-ea88-4e8f-b80f-911217e6ab8f@github.com>

On Fri, 29 Mar 2024 18:37:11 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reveiw updates and SizeMinimizedTest converted to auto test
>
> test/jdk/java/awt/Frame/MegaIconTest/MegaIconTest.java line 194:
> 
>> 192:         setLayout(new BorderLayout());
>> 193: 
>> 194:         //Add the icon graphic and instructions to the Frame
> 
> The background transparency of different gifs can be checked by setting the background of the Frame to a different color.  For instance `setBackground(Color.YELLOW)` here and in the original test.
> 
> Adding a different background color instead of white makes it easier for the tester to compare the different types of icon.

Good suggestion about setting different background Color, but here since the classes extended from one another, it would be difficult to set different background Color for each icon.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1547132740

From tr at openjdk.org  Tue Apr  2 04:51:26 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Apr 2024 04:51:26 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v6]
In-Reply-To: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
Message-ID: <6YAbjBsERQEhQLjlMaxjYSFD4KLKmfrP22uISEr3i10=.ac9a1820-cbbf-453b-b1b7-9c55d747a266@github.com>

> Convert and open source these manual applet test to main based:
> java/awt/Frame/MegaIconTest/MegaIconTest.html
> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
> 
> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.

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

  Reveiw updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18448/files
  - new: https://git.openjdk.org/jdk/pull/18448/files/20517050..1e9e5f28

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

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

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

From tr at openjdk.org  Tue Apr  2 04:51:27 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Apr 2024 04:51:27 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
 <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
Message-ID: <IHmOKa2J6WMH7iW8SLcQYDcI4EUugr0dG41qeA_uww4=.ed33130d-9e08-4c3c-a26c-cdfefea50590@github.com>

On Fri, 29 Mar 2024 18:41:01 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reveiw updates and SizeMinimizedTest converted to auto test
>
> test/jdk/java/awt/Frame/MegaIconTest/MegaIconTest.java line 58:
> 
>> 56:         String INSTRUCTIONS = """
>> 57:                 Each of the buttons in the main window represents a test
>> 58:                 of certain icon functionality - transparency/opacity, scaling etc.
> 
> The instructions would be more clear if stated as - **background transparency/opacity of the icon**.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1547134880

From tr at openjdk.org  Tue Apr  2 04:57:01 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Apr 2024 04:57:01 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext
In-Reply-To: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
Message-ID: <7__n5YrnHgjYrz95jptetjj84-ssDiFPnwCJ6XCKddU=.4c36e236-5d51-48b9-8d28-5d6e8c809ed7@github.com>

On Mon, 1 Apr 2024 22:53:12 GMT, Larry Cable <duke at openjdk.org> wrote:

> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
> 
> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
> 
> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
> 
> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

Marked as reviewed by tr (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18569#pullrequestreview-1972614085

From iris at openjdk.org  Tue Apr  2 05:12:59 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 2 Apr 2024 05:12:59 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext
In-Reply-To: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
Message-ID: <f3X2PsMxvXuaI3nfH2t-c2ijSKyre9PXCpvB9UMvmEY=.4c50d307-bf0d-4065-816c-38918673cc31@github.com>

On Mon, 1 Apr 2024 22:53:12 GMT, Larry Cable <duke at openjdk.org> wrote:

> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
> 
> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
> 
> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
> 
> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

Recommend java.beans.beancontext package.html be modified to include a deprecation note similar to the one present in java.applet package.html: 

> This package has been deprecated and may be removed in a future version of the Java Platform. There is no replacement. All of the classes and interfaces in this package have been terminally deprecated. Users are advised to migrate their applications to other technologies.

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

PR Review: https://git.openjdk.org/jdk/pull/18569#pullrequestreview-1972627385

From tr at openjdk.org  Tue Apr  2 06:38:03 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 2 Apr 2024 06:38:03 GMT
Subject: RFR: 8327137: Add test for ConcurrentModificationException in
 BasicDirectoryModel [v3]
In-Reply-To: <UUsO_EIt0zPtpVszwLEVfDD-oBjT2UBnsbvdd9746-g=.9a6d10be-825a-4388-adfd-21b79e0f8731@github.com>
References: <mCqqjrXVWDB2PvpOhKHx-Hr8W6tUz6v4stztGmyAeEg=.1f95da1c-e1a5-40be-be8b-0758729fa9b9@github.com>
 <UUsO_EIt0zPtpVszwLEVfDD-oBjT2UBnsbvdd9746-g=.9a6d10be-825a-4388-adfd-21b79e0f8731@github.com>
Message-ID: <EdmwhB_RXz_PHpqV2NtO0H9TXeB6sB6u-P1a278wKh8=.c054b583-4674-4b85-8154-af6156a457ec@github.com>

On Fri, 15 Mar 2024 14:45:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> I'm adding a regression test for [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670) and [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091); it's also a regression test for [JDK-8240690](https://bugs.openjdk.org/browse/JDK-8240690).
>> 
>> I referenced this test in PR #17462 in [this comment](https://github.com/openjdk/jdk/pull/17462#issuecomment-1914844026). I fine-tuned the test since that time.
>> 
>> The test doesn't fail all the time without the fix for JDK-8323670, however, it fails sometimes. If you run the test several times, it will likely fail _without the fix_.
>> 
>> For me, the test fails about 10 times from 40 runs in the CI. It fails on macOS more frequently than on Linux.
>> 
>> When the test passes, it usually completes in 5 minutes.
>> 
>> **How the test works**
>> 
>> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
>> 
>> The test starts several _scanner_ threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
>> 
>> A timer is used to create new files in the directory that the file chooser is using.
>> 
>> After enumerating the files, the File Loading Thread posts an event to EDT. The event updates `fileCache` and fires a `ListDataEvent`.
>> 
>> If the File Loading Thread is iterating over `fileCache` using `Iterator` (when `fileCache.subList` or `fileCache.equals` is running; or a new `Vector` instance is created from a `fileCache` or its sublist) and `fileCache` is being updated on EDT, then `ConcurrentModificationException` is thrown.
>> 
>> On Linux and on _headless_ macOS, `ShellFolder.invoke` is executed in the caller, which makes it easier to reproduce the issue. Because of [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179), there are several File Loading Threads, which also helps to reproduce the issue.
>> 
>> On _headful_ macOS, the `BasicDirectoryModel` is not used, so the test does not reproduce the issue.
>> 
>> On Windows, the test does not fail or fails with `OutOfMemoryError`. It is because all the File Loading Threads are serialised on the COM thread, `ShellFolder.invoke` submits the task to the COM thread and waits for i...
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suppress throwing exceptions while deleting files

Looks good to me.

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18109#pullrequestreview-1972734171

From manc at openjdk.org  Tue Apr  2 07:29:06 2024
From: manc at openjdk.org (Man Cao)
Date: Tue, 2 Apr 2024 07:29:06 GMT
Subject: Integrated: 8329352: Remove dead code in splashscreen_sys.c
In-Reply-To: <xe-wpIn8dHrfbjI1ZlHq4ad_s4UHnH7_ZDPB1kucFrM=.8a0a0d84-683c-40cc-ace1-e887abd58a10@github.com>
References: <xe-wpIn8dHrfbjI1ZlHq4ad_s4UHnH7_ZDPB1kucFrM=.8a0a0d84-683c-40cc-ace1-e887abd58a10@github.com>
Message-ID: <lyyecFgW0U7mZrQOUjKlUBH6LlJS1HA7L3m3y_v1oCU=.301daf5b-a199-4fc2-99f4-b15d387d1160@github.com>

On Fri, 29 Mar 2024 23:00:56 GMT, Man Cao <manc at openjdk.org> wrote:

> Hi all,
> 
> Could anyone review this trivial change to remove dead code in splashscreen_sys.c?
> 
> -Man

This pull request has now been integrated.

Changeset: 816638e3
Author:    Man Cao <manc at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/816638e3bedef9f57c438dfd2f9837acbb93ff90
Stats:     32 lines in 1 file changed: 0 ins; 31 del; 1 mod

8329352: Remove dead code in splashscreen_sys.c

Reviewed-by: jiefu, prr

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

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

From djelinski at openjdk.org  Tue Apr  2 08:35:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 2 Apr 2024 08:35:09 GMT
Subject: RFR: 8329340: Remove unused libawt code
In-Reply-To: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
Message-ID: <z50nx42az913TD18PipZivQ85Dmtm1K-sVeDWYNxqvU=.33d5dbfc-b5d1-49d5-80e6-b450cd943866@github.com>

On Fri, 29 Mar 2024 18:23:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
> 
> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
> 
> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.

Thanks for the review! Should I wait for a second one?

Also, what's your definition of "early in the week"? Should I wait for Monday, or does anything other than Friday qualify?

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

PR Comment: https://git.openjdk.org/jdk/pull/18553#issuecomment-2031395021

From aivanov at openjdk.org  Tue Apr  2 10:34:05 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 10:34:05 GMT
Subject: Integrated: 8329320: Simplify awt/print/PageFormat/NullPaper.java test
In-Reply-To: <0CQ06Dw6Uwa9Z2lLfqFhdAWxWVLiYJs-EoziVLODxlw=.0133d820-1a13-4813-bc20-c9358fcbc58c@github.com>
References: <0CQ06Dw6Uwa9Z2lLfqFhdAWxWVLiYJs-EoziVLODxlw=.0133d820-1a13-4813-bc20-c9358fcbc58c@github.com>
Message-ID: <w97UhL7xEAkrw9dtVv8lhfAYmzr28Pqw6NbCrU-Fldk=.2903f1b1-4f48-40d6-b3ab-efbf4215e7d0@github.com>

On Fri, 29 Mar 2024 12:45:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove all the leftovers of the _"standard instructions" machinery_ from the `NullPaper.java` test.
> 
> The test code consists of two lines now: concise and clear.

This pull request has now been integrated.

Changeset: 5cf457b7
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cf457b74334c08bab40e2e6c1a8544a2555fb82
Stats:     177 lines in 1 file changed: 6 ins; 155 del; 16 mod

8329320: Simplify awt/print/PageFormat/NullPaper.java test

Reviewed-by: honkar, prr

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

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

From aivanov at openjdk.org  Tue Apr  2 10:38:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 10:38:07 GMT
Subject: RFR: 8329510: Update ProblemList for
 JFileChooser/8194044/FileSystemRootTest.java
Message-ID: <QDbaHbypmsltrQkLn_jhQsVvu3syniL6tkPYczy7rVs=.9f78e299-ad12-40f4-a89f-976ad5e6e1be@github.com>

Update the problem-list entry for ` javax/swing/JFileChooser/8194044/FileSystemRootTest.java` to refer to [JDK-8327236](https://bugs.openjdk.org/browse/JDK-8327236) under which the failure with `"root drive reported as false"` is tracked.

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

Commit messages:
 - 8329510: Update ProblemList for JFileChooser/8194044/FileSystemRootTest.java

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

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

From aivanov at openjdk.org  Tue Apr  2 11:04:06 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 11:04:06 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v15]
In-Reply-To: <UjyKUWJu0ZuUx6a1bZdn8v9mmfKPtrocxHm-nw358FQ=.23894605-c737-44d9-a1c8-6c9bdc008b15@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
 <UjyKUWJu0ZuUx6a1bZdn8v9mmfKPtrocxHm-nw358FQ=.23894605-c737-44d9-a1c8-6c9bdc008b15@github.com>
Message-ID: <KzRxQWFAIX3gj-jetPdueKK33WN-_XvPFS7Iu9swg34=.cdfe3714-73b8-42fd-b1d3-c2395028146b@github.com>

On Mon, 1 Apr 2024 05:38:54 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
>> 
>> Please review and let me know your suggestions.
>> 
>> Regards,
>> Renjith
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimized switch case

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/print/PrinterJob/ValidatePage/ValidatePage.java line 67:

> 65: 
> 66:     private static String GetOrientation(int o)
> 67:     {

Follow Java Coding Style:
Suggestion:

    private static String getOrientation(int o) {

Method names start with lower-case letter; the opening brace is on the same line as the construct it opens.

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

PR Review: https://git.openjdk.org/jdk/pull/17607#pullrequestreview-1973401767
PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1547631488

From aivanov at openjdk.org  Tue Apr  2 11:07:04 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 11:07:04 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v15]
In-Reply-To: <UjyKUWJu0ZuUx6a1bZdn8v9mmfKPtrocxHm-nw358FQ=.23894605-c737-44d9-a1c8-6c9bdc008b15@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
 <UjyKUWJu0ZuUx6a1bZdn8v9mmfKPtrocxHm-nw358FQ=.23894605-c737-44d9-a1c8-6c9bdc008b15@github.com>
Message-ID: <xOgBS58Lf16tAPK_-qrgH5LXAjqs_XGCllw-WFJDBtw=.d05ddbea-d5b7-4db2-a0a1-08250ddc4582@github.com>

On Mon, 1 Apr 2024 05:38:54 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
>> 
>> Please review and let me know your suggestions.
>> 
>> Regards,
>> Renjith
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimized switch case

[This issue](https://github.com/openjdk/jdk/pull/17607#discussion_r1542061869) remains unresolved. Specifically, `PrintAllFonts.java` should fail the test if the user clicks Cancel in the Print Dialog.

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

PR Comment: https://git.openjdk.org/jdk/pull/17607#issuecomment-2031711380

From aivanov at openjdk.org  Tue Apr  2 11:08:01 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 11:08:01 GMT
Subject: RFR: 8324807 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 2 [v14]
In-Reply-To: <X6V45_rBk_h5XI8N3Dh-tFNpG7Eq7yAqfXHxZntGZS0=.7c504ec1-16f2-43fe-9077-da573ff286f6@github.com>
References: <UZ9jtQbkj-MoeLoccJnd2_3ciCCy9n-CD5vDv0hVKME=.f67db96d-92e6-46a1-9bb6-4fe77c9a8c4e@github.com>
 <X6V45_rBk_h5XI8N3Dh-tFNpG7Eq7yAqfXHxZntGZS0=.7c504ec1-16f2-43fe-9077-da573ff286f6@github.com>
Message-ID: <DMdgl-_7FzPkP1CroINHF_wPG8dJkr1XuL1GyX2hSdU=.ce818b84-d04c-4621-b669-1b548020a21c@github.com>

On Mon, 1 Apr 2024 06:34:49 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
>> 
>> Please review and let me know your suggestions.
>> 
>> Regards,
>> Renjith
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions integrated

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17608#pullrequestreview-1973414300

From rkannathpari at openjdk.org  Tue Apr  2 11:19:15 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 2 Apr 2024 11:19:15 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v16]
In-Reply-To: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
Message-ID: <Oxt8IqE-YJP8yygUYuKGAPcDahsgl5mhNYAIvE7x3MY=.7ea5d5bd-514b-4add-9fff-33bea4f11a72@github.com>

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Force fail added for user cancel case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17607/files
  - new: https://git.openjdk.org/jdk/pull/17607/files/cd8d67dd..5991937f

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

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

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

From aivanov at openjdk.org  Tue Apr  2 11:27:11 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 11:27:11 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v16]
In-Reply-To: <Oxt8IqE-YJP8yygUYuKGAPcDahsgl5mhNYAIvE7x3MY=.7ea5d5bd-514b-4add-9fff-33bea4f11a72@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
 <Oxt8IqE-YJP8yygUYuKGAPcDahsgl5mhNYAIvE7x3MY=.7ea5d5bd-514b-4add-9fff-33bea4f11a72@github.com>
Message-ID: <sVazLnnxUFV72KvZfZWFpqf6nQr2dT85P-xONGemGBU=.45ee5510-6953-4bbb-be68-2d4bc3960a1e@github.com>

On Tue, 2 Apr 2024 11:19:15 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
>> 
>> Please review and let me know your suggestions.
>> 
>> Regards,
>> Renjith
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Force fail added for user cancel case

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/print/PrinterJob/ValidatePage/ValidatePage.java line 66:

> 64:     Label myOrientationLabel;
> 65: 
> 66:     private static String GetOrientation(int o) {

Suggestion:

    private static String getOrientation(int o) {

The method name should start with *a lower-case letter*. And the call sites need updating too.

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

PR Review: https://git.openjdk.org/jdk/pull/17607#pullrequestreview-1973469667
PR Review Comment: https://git.openjdk.org/jdk/pull/17607#discussion_r1547674525

From rkannathpari at openjdk.org  Tue Apr  2 11:29:11 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 2 Apr 2024 11:29:11 GMT
Subject: Integrated: 8324807 : Manual printer tests have no Pass/Fail buttons, 
 instructions close set 2
In-Reply-To: <UZ9jtQbkj-MoeLoccJnd2_3ciCCy9n-CD5vDv0hVKME=.f67db96d-92e6-46a1-9bb6-4fe77c9a8c4e@github.com>
References: <UZ9jtQbkj-MoeLoccJnd2_3ciCCy9n-CD5vDv0hVKME=.f67db96d-92e6-46a1-9bb6-4fe77c9a8c4e@github.com>
Message-ID: <VKKqLYBSc93VHbNRfx_GkhTtrOf7DmNqN7g5iWMvDGI=.d082e581-cdd4-4eb8-8c0c-74ba4865914b@github.com>

On Mon, 29 Jan 2024 06:52:01 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

This pull request has now been integrated.

Changeset: ed821cbe
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed821cbe857363e049f3c640ae4546c340a577ac
Stats:     1299 lines in 6 files changed: 230 ins; 902 del; 167 mod

8324807: Manual printer tests have no Pass/Fail buttons, instructions close set 2

Reviewed-by: tr, achung, aivanov

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

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

From ihse at openjdk.org  Tue Apr  2 13:05:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 2 Apr 2024 13:05:28 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v70]
In-Reply-To: <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
Message-ID: <cQmPjcn41WFl8b944lgKOUUBBIPVcRV_uzkEIO4XNww=.ff7d6bfb-a175-4b94-90c3-aba73f5e3330@github.com>

On Thu, 28 Mar 2024 07:36:04 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 four additional commits since the last revision:
> 
>  - Labels to empty line in awt_Window.cpp
>  - Labels to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp
>  - Label to empty line in awt_Window.cpp

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

> 232:     c->m_eraseBackgroundOnResize = doEraseOnResize;
> 233: 
> 234: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6586:

> 6584:     component->GetInsets(gis->insets);
> 6585: 
> 6586: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1603:

> 1601:     } else {
> 1602:         f = (AwtFrame *) JNI_GET_PDATA(peer);
> 1603:         if (f == nullptr) {

@prrace What is the current take on `NULL` vs `nullptr` in client code? I know Hotspot made an effort to completely purge all `NULL` references. 

The new code here uses a mix of `NULL` and `nullprt`. Should it:
a) only use `NULL`
b) only use `nullptr`
c) remain as it is
?

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

> 212: static const double POINTS_TO_LOMETRIC = (254.0 / 72.0);
> 213: 
> 214: 

I recommend deleting one more line, since otherwise you will now have three consecutive blank lines.

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

> 1029:     window->RepositionSecurityWarning(env);
> 1030: 
> 1031:   ret:

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

> 3157:     }
> 3158: 
> 3159: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

> 3191:     }
> 3192: 
> 3193: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

> 3222:     window->SetTranslucency(iOpacity, window->isOpaque());
> 3223: 
> 3224: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

> 3253:     window->SetTranslucency(window->getOpacity(), isOpaque);
> 3254: 
> 3255: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

> 3291:                          uws->hBitmap);
> 3292: 
> 3293: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

> 3326:     window->setFullScreenExclusiveModeState(state != 0);
> 3327: 
> 3328: 

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547824279
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547824797
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547829415
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547830886
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547833185
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547836998
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547837189
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547837344
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547837450
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547837625
PR Review Comment: https://git.openjdk.org/jdk/pull/15096#discussion_r1547837761

From ihse at openjdk.org  Tue Apr  2 13:05:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 2 Apr 2024 13:05:29 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v52]
In-Reply-To: <6_80radA3v1Fq_kuf_4GZ74gfwc8hgMPOyBczHItlKc=.9a2463ef-c106-42c4-b0a8-12f94568ea96@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <0p1UVaUOt2bs1mkuBV1liUxBYGRhnKnclf1x_-Y22GE=.2de6c2c4-8cf5-470d-bdb3-cd0dd0e13975@github.com>
 <6_80radA3v1Fq_kuf_4GZ74gfwc8hgMPOyBczHItlKc=.9a2463ef-c106-42c4-b0a8-12f94568ea96@github.com>
Message-ID: <c2SEU9Ldurjf6hDD1oIOuTiXLdcdOYFHU5PgJy0IsoY=.55e902c7-e331-4657-ab4d-f970625e8b59@github.com>

On Fri, 22 Mar 2024 12:26:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert Formatting in awt_Component.cpp
>>  - Revert Formatting in awt_Window.cpp
>
> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 779:
> 
>> 777:     }
>> 778: 
>> 779: 
> 
> Suggestion:

To be clear: I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

> src/java.desktop/windows/native/libawt/windows/awt_PrintJob.cpp line 1316:
> 
>> 1314:     env->CallVoidMethod(newPaper, setImageableID, ix, iy, iw, ih);
>> 1315: 
>> 1316: 
> 
> Suggestion:

I recommend deleting this line, since it does not make sense to have two consecutive blank lines here.

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

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

From ihse at openjdk.org  Tue Apr  2 13:05:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 2 Apr 2024 13:05:31 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v46]
In-Reply-To: <QfIBrG8rqxy__rPSCMddlNATjmEEr4ccSoZyjFckjUg=.b7f6fffb-2cf9-4c54-a35c-b01f5fd654de@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <5WJnl6Z9RyYzZrDStf9p74gus07Stz6S6NHwVpGQO3M=.0a04a120-77b5-48c3-9ae8-7d37c9646463@github.com>
 <QfIBrG8rqxy__rPSCMddlNATjmEEr4ccSoZyjFckjUg=.b7f6fffb-2cf9-4c54-a35c-b01f5fd654de@github.com>
Message-ID: <zcbYqHLjg8NJaaYnsG9MMBYbb25CzQ13kfF1MOyfVLI=.8bdcfeba-11ee-4fe6-80f0-a7a146db5ede@github.com>

On Sat, 20 Jan 2024 00:38:04 GMT, Phil Race <prr at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 79 commits:
>> 
>>  - Merge branch 'openjdk:master' into patch-10
>>  - Merge branch 'openjdk:master' into patch-10
>>  - Fix awt_Window.cpp
>>  - Fix awt_PrintJob.cpp
>>  - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4
>>  - Fix awt_Window.cpp
>>  - awt_Window.cpp
>>  - awt_PrintJob.cpp
>>  - awt_Frame.cpp
>>  - Whitespace awt_Component.cpp
>>  - ... and 69 more: https://git.openjdk.org/jdk/compare/35e96627...cbfbaee6
>
> src/java.desktop/windows/native/libawt/windows/awt_Window.cpp line 3137:
> 
>> 3135: 
>> 3136:     PDATA pData = JNI_GET_PDATA(self);
>> 3137:     if (self == NULL) {
> 
> Surely line 3136 above should have been deleted ? It is replaced by line 3143 below.
> And then you can also directly set window, pData isn't needed, as discussed in similar cases above

Yes. 

@TheShermanTanker This is in fact a serious bug. You try to do `pData = JNI_GET_PDATA(self)` before the null check of self, and this will crash if self is null.

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

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

From aivanov at openjdk.org  Tue Apr  2 13:07:03 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 13:07:03 GMT
Subject: RFR: 8329340: Remove unused libawt code
In-Reply-To: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
Message-ID: <LzO_Py9AfEZ6c8vZGxs6G5GG0CyA3-mVtO5QnUb7_Ms=.672bddc6-ed57-471d-99f2-c4a1c72219d1@github.com>

On Fri, 29 Mar 2024 18:23:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
> 
> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
> 
> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.

Looks good to me.

src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp line 111:

> 109:  * DTRACE print callback to dump window's update region bounding rectangle
> 110:  */
> 111: void DumpUpdateRectangle(const char * file, int line, int argc, const char * fmt, va_list arglist) {

Can these functions be useful for debugging?

Does it make sense to hide them unless `DEBUG` is defined?

src/java.desktop/windows/native/libawt/windows/awtmsg.h line 224:

> 222: 
> 223:     /* deleted DND mesg's */
> 224: 

I guess this comment can safely be removed. What does it add? There had been some messages that were removed a long time ago.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18553#pullrequestreview-1973710651
PR Review Comment: https://git.openjdk.org/jdk/pull/18553#discussion_r1547819832
PR Review Comment: https://git.openjdk.org/jdk/pull/18553#discussion_r1547841399

From abhiscxk at openjdk.org  Tue Apr  2 13:08:45 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 2 Apr 2024 13:08:45 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v5]
In-Reply-To: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
Message-ID: <DPXfVjbcNWXCDxHwj-6-FiRS8t5opWd9oiKtW8yf3WQ=.203dd246-d415-4412-b21c-0fc4ff28cf8d@github.com>

> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
> 
> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
> 
> 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 seven additional commits since the last revision:

 - Title Update
 - Text Block and PassFailJFrame update
 - Merge
 - condition combined
 - Remove WindowsLAF check
 - spacing fix
 - TabbedPane background color fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17720/files
  - new: https://git.openjdk.org/jdk/pull/17720/files/05573261..563be986

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

  Stats: 1432234 lines in 12032 files changed: 312658 ins; 679613 del; 439963 mod
  Patch: https://git.openjdk.org/jdk/pull/17720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17720/head:pull/17720

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

From aivanov at openjdk.org  Tue Apr  2 13:12:03 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 13:12:03 GMT
Subject: RFR: 8329340: Remove unused libawt code
In-Reply-To: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
Message-ID: <kV9-B4SoKiTy57YAtvjy6w-fSXeXbSsA674HL802F1M=.9b6457f1-e543-4934-b801-423c1fd3c408@github.com>

On Fri, 29 Mar 2024 18:23:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
> 
> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
> 
> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.

You should add [JDK-8315693](https://bugs.openjdk.org/browse/JDK-8315693): _Remove WM_AWT_SET_SCROLL_INFO message_ to the list of resolved issues.

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

PR Comment: https://git.openjdk.org/jdk/pull/18553#issuecomment-2031998788

From aivanov at openjdk.org  Tue Apr  2 13:23:02 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 13:23:02 GMT
Subject: RFR: 8329340: Remove unused libawt code
In-Reply-To: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
Message-ID: <_C-JE_THwsFfxL2r-iWudPzRcLWG6LinDL48-zgiOVU=.6257d69b-1569-49dc-8cc4-e04ca8dc4be2@github.com>

On Fri, 29 Mar 2024 18:23:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
> 
> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
> 
> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.

You should also update the copyright years where applicable.

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

PR Comment: https://git.openjdk.org/jdk/pull/18553#issuecomment-2032026324

From aivanov at openjdk.org  Tue Apr  2 13:25:20 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 13:25:20 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v17]
In-Reply-To: <dd83el1zTiK3sejgXdyNqbxdYP0ZkgHWNiyShTYRR6A=.5f3b08e3-2fb8-4acf-a1f2-b17650c2c719@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
 <dd83el1zTiK3sejgXdyNqbxdYP0ZkgHWNiyShTYRR6A=.5f3b08e3-2fb8-4acf-a1f2-b17650c2c719@github.com>
Message-ID: <zYV3gR1gkvbcjlXN8q28kCIa0ZKyizgn4qUARqPq9Wc=.f6e0c0a9-08c7-4284-9a7e-8a4c8b03733b@github.com>

On Tue, 2 Apr 2024 13:22:27 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
>> 
>> Please review and let me know your suggestions.
>> 
>> Regards,
>> Renjith
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Function name updated

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17607#pullrequestreview-1973795768

From rkannathpari at openjdk.org  Tue Apr  2 13:25:20 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 2 Apr 2024 13:25:20 GMT
Subject: Integrated: 8320676 : Manual printer tests have no Pass/Fail buttons, 
 instructions close set 1
In-Reply-To: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
Message-ID: <CghK317G5dGJGIkJqItWO6cReNe0PhI4G36plFKkRHo=.2d0d7635-7e0f-4810-8831-36f8c70c10f3@github.com>

On Mon, 29 Jan 2024 06:24:29 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

This pull request has now been integrated.

Changeset: 7eb78e33
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7eb78e332080df3890b66ca04338a4ba69af45eb
Stats:     1723 lines in 5 files changed: 438 ins; 1014 del; 271 mod

8320676: Manual printer tests have no Pass/Fail buttons, instructions close set 1

Reviewed-by: honkar, achung, aivanov

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

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

From rkannathpari at openjdk.org  Tue Apr  2 13:25:19 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 2 Apr 2024 13:25:19 GMT
Subject: RFR: 8320676 : Manual printer tests have no Pass/Fail buttons,
 instructions close set 1 [v17]
In-Reply-To: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
References: <Afd90FypFvXYNR17jgkxcFj2LlxdLlZ1Bgd7WctdKcU=.2a8b05e0-a476-4598-8524-a22a0f54b8a5@github.com>
Message-ID: <dd83el1zTiK3sejgXdyNqbxdYP0ZkgHWNiyShTYRR6A=.5f3b08e3-2fb8-4acf-a1f2-b17650c2c719@github.com>

> Hi Reviewers,
> 
> Updated manual printer test cases with 'PassFailJFrame', also removed unused variables. Added 'SkippedException' in case of printer missing or not configured.
> 
> Please review and let me know your suggestions.
> 
> Regards,
> Renjith

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Function name updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17607/files
  - new: https://git.openjdk.org/jdk/pull/17607/files/5991937f..03b4076d

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

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

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

From ihse at openjdk.org  Tue Apr  2 15:53:25 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 2 Apr 2024 15:53:25 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v70]
In-Reply-To: <H8DdyOjIYbpj5JxJDTW0-t92A9aUnY1Bquz02XWgFEk=.53238f29-59cf-4bfa-a131-cde8eae1d662@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
 <H8DdyOjIYbpj5JxJDTW0-t92A9aUnY1Bquz02XWgFEk=.53238f29-59cf-4bfa-a131-cde8eae1d662@github.com>
Message-ID: <ZimNrXlfIzTWnaYe0fYLSk5JhKKxjiyEb4vVA2Uijg0=.a6da7702-a85f-435f-afde-3a9351b9c016@github.com>

On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Labels to empty line in awt_Window.cpp
>>  - Labels to empty line in awt_Window.cpp
>>  - Label to empty line in awt_Window.cpp
>>  - Label to empty line in awt_Window.cpp
>
> Bumping

@TheShermanTanker I tried to help you get this done. I added fixes to a copy of your branch on my personal fork, but then it turned out I could not push them to your branch. :-(

It ended up with me creating a new PR, https://github.com/openjdk/jdk/pull/18584. As a bonus, I think it might be easier to review with a fresh start. This PR has grown quite heavy with lots of comments and commits.

I hope you don't feel like I'm stealing this away from you. You have done a great job, and shown a lot of patience of carrying this all the way here. But I also got the impression that you would appreciate my assistance in getting the last pieces in place so we can integrate this.

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

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

From serb at openjdk.org  Tue Apr  2 15:55:11 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 2 Apr 2024 15:55:11 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext
In-Reply-To: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
Message-ID: <DXA4qkbi3Ms8vawT0VlVfeR7mNCjGmDCgy_1PY_9Mnk=.53bcce2a-dea1-43ec-8adf-ddf3f1727dde@github.com>

On Mon, 1 Apr 2024 22:53:12 GMT, Larry Cable <duke at openjdk.org> wrote:

> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
> 
> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
> 
> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
> 
> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

> public code corpus should be searched prior to removal in order to determine impact.

What are results of that search?

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

PR Comment: https://git.openjdk.org/jdk/pull/18569#issuecomment-2032434587

From djelinski at openjdk.org  Tue Apr  2 16:58:02 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 2 Apr 2024 16:58:02 GMT
Subject: RFR: 8329340: Remove unused libawt code
In-Reply-To: <LzO_Py9AfEZ6c8vZGxs6G5GG0CyA3-mVtO5QnUb7_Ms=.672bddc6-ed57-471d-99f2-c4a1c72219d1@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
 <LzO_Py9AfEZ6c8vZGxs6G5GG0CyA3-mVtO5QnUb7_Ms=.672bddc6-ed57-471d-99f2-c4a1c72219d1@github.com>
Message-ID: <ORmg8fVATsZcMmSLeQTSwLMZrx3-Z3H0P03MLuv9mW0=.22cb8c5f-6bc1-4f90-8df7-54605accd968@github.com>

On Tue, 2 Apr 2024 12:50:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
>> 
>> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
>> 
>> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.
>
> src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp line 111:
> 
>> 109:  * DTRACE print callback to dump window's update region bounding rectangle
>> 110:  */
>> 111: void DumpUpdateRectangle(const char * file, int line, int argc, const char * fmt, va_list arglist) {
> 
> Can these functions be useful for debugging?
> 
> Does it make sense to hide them unless `DEBUG` is defined?

they were `if defined(DEBUG)` already; I can keep them if you think it makes sense.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18553#discussion_r1548244729

From duke at openjdk.org  Tue Apr  2 16:58:19 2024
From: duke at openjdk.org (Larry Cable)
Date: Tue, 2 Apr 2024 16:58:19 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v2]
In-Reply-To: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
Message-ID: <xsB-qrz5sW5_KikA0CGqjv909VezEsThw9J2gqORHPE=.b698d508-8c2a-4825-977a-7af8c69b762e@github.com>

> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
> 
> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
> 
> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
> 
> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

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

 - Merge branch 'openjdk:master' into 8321428
 - added deprecation message to package-info as requested
 - 8321428: Deprecate for removal the package java.beans.beancontext

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18569/files
  - new: https://git.openjdk.org/jdk/pull/18569/files/4e6aef0b..ff50d1a8

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

  Stats: 385074 lines in 3334 files changed: 32128 ins; 25872 del; 327074 mod
  Patch: https://git.openjdk.org/jdk/pull/18569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18569/head:pull/18569

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

From aivanov at openjdk.org  Tue Apr  2 17:06:09 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 17:06:09 GMT
Subject: RFR: JDK-8328753 : Open source few Undecorated Frame tests [v3]
In-Reply-To: <erA5EWbQxnZGfvc5qdQ5N1jT1wgrAIvQu8n-K_yiqzU=.07148e01-3211-4d6b-b50e-a745fe5e27a5@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
 <erA5EWbQxnZGfvc5qdQ5N1jT1wgrAIvQu8n-K_yiqzU=.07148e01-3211-4d6b-b50e-a745fe5e27a5@github.com>
Message-ID: <LghPSKnIodGHpRwLAEl6rW9-6AIWw-bFMduwTHZ4tAw=.7f49605a-38a1-4e20-a2ea-8a1e6ae44532@github.com>

On Fri, 29 Mar 2024 17:29:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Following tests are converted to main and open-sourced:
>> 
>> - /java/awt/Frame/FrameDialogMixedTest.java- Converted to main/manual using PassFailJFrame.
>> - /java/awt/Frame/MaximizeUndecoratedTest.java - Automated
>> - /java/awt/Frame/MinimizeUndecoratedTest.java - Automated
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RuntimeException thrown

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18523#pullrequestreview-1974434589

From aivanov at openjdk.org  Tue Apr  2 17:08:59 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 17:08:59 GMT
Subject: RFR: JDK-8328753 : Open source few Undecorated Frame tests [v2]
In-Reply-To: <APULaNZx8QwktRNrBPri6bedt1yzrnC9xPFv0bVN2dc=.0d2d64b4-dd06-4038-80ae-8dca78ad71d6@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
 <KBCwA1lSI3j1IgH_Mc72T8vLYxJIaTs8JjsMLsdY2sY=.52705506-3af7-4988-94fa-5271398f1932@github.com>
 <PE5Dgy_IBGTmcNA__6qJTRSPhRLnqtgCUxYPkXOqCAc=.f6dd7d82-abdf-4942-b458-2539ea14c4c5@github.com>
 <APULaNZx8QwktRNrBPri6bedt1yzrnC9xPFv0bVN2dc=.0d2d64b4-dd06-4038-80ae-8dca78ad71d6@github.com>
Message-ID: <RU8MvrHUNqzU7AH2rWRbHlfgNFr25xoqZ8nGbrxCgRI=.31e7db1e-bc95-495a-b4bf-bc0735b44cc3@github.com>

On Fri, 29 Mar 2024 17:25:38 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> It is better to re-throw it as RuntimeException. Updated.

Not really?

If saving the image fails, we want to preserve *the original error message* which wasn't even thrown by this time. So printing stack trace in this particular is quite safe, the exception could be ignored completely.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18523#discussion_r1548260371

From djelinski at openjdk.org  Tue Apr  2 17:10:18 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 2 Apr 2024 17:10:18 GMT
Subject: RFR: 8329340: Remove unused libawt code [v2]
In-Reply-To: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
Message-ID: <oWhZA1gERLk-AcEVSgQ5_8SzN2C2a6NzLhk8mpXmOX8=.eddc2fde-abc3-4d1a-ad6c-abe5bbb248fa@github.com>

> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
> 
> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
> 
> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.

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

 - Update copyright
 - Remove comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18553/files
  - new: https://git.openjdk.org/jdk/pull/18553/files/cbf7bbd3..8041a97c

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

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

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

From aivanov at openjdk.org  Tue Apr  2 17:14:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 17:14:10 GMT
Subject: RFR: JDK-8328753 : Open source few Undecorated Frame tests [v3]
In-Reply-To: <erA5EWbQxnZGfvc5qdQ5N1jT1wgrAIvQu8n-K_yiqzU=.07148e01-3211-4d6b-b50e-a745fe5e27a5@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
 <erA5EWbQxnZGfvc5qdQ5N1jT1wgrAIvQu8n-K_yiqzU=.07148e01-3211-4d6b-b50e-a745fe5e27a5@github.com>
Message-ID: <2A613mykBCUuAONL-sbXDS1to3wis1DzgNpw7iaAHow=.c1ac209d-ba68-4db5-a541-af08e2c94c52@github.com>

On Fri, 29 Mar 2024 17:29:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Following tests are converted to main and open-sourced:
>> 
>> - /java/awt/Frame/FrameDialogMixedTest.java- Converted to main/manual using PassFailJFrame.
>> - /java/awt/Frame/MaximizeUndecoratedTest.java - Automated
>> - /java/awt/Frame/MinimizeUndecoratedTest.java - Automated
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   RuntimeException thrown

test/jdk/java/awt/Frame/MinimizeUndecoratedTest.java line 98:

> 96:             } else {
> 97:                 throw new RuntimeException("Window iconified event not received.");
> 98:             }

I'd invert the condition of the `if (!isMinimized())`, then everything inside the body of the `if`-block can be unindented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18523#discussion_r1548267940

From iris at openjdk.org  Tue Apr  2 17:20:13 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 2 Apr 2024 17:20:13 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v2]
In-Reply-To: <xsB-qrz5sW5_KikA0CGqjv909VezEsThw9J2gqORHPE=.b698d508-8c2a-4825-977a-7af8c69b762e@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
 <xsB-qrz5sW5_KikA0CGqjv909VezEsThw9J2gqORHPE=.b698d508-8c2a-4825-977a-7af8c69b762e@github.com>
Message-ID: <X0FvuL2IsBkezl4VfoZMz3TKgaK-dpEyQ6wV7Lysf3w=.59616c9a-60d3-452a-b26e-75b0fea939c5@github.com>

On Tue, 2 Apr 2024 16:58:19 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
>> 
>> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
>> 
>> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
>> 
>> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**
>
> Larry Cable has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8321428
>  - added deprecation message to package-info as requested
>  - 8321428: Deprecate for removal the package java.beans.beancontext

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18569#pullrequestreview-1974465579

From aivanov at openjdk.org  Tue Apr  2 17:22:14 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 17:22:14 GMT
Subject: RFR: 8329340: Remove unused libawt code [v2]
In-Reply-To: <oWhZA1gERLk-AcEVSgQ5_8SzN2C2a6NzLhk8mpXmOX8=.eddc2fde-abc3-4d1a-ad6c-abe5bbb248fa@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
 <oWhZA1gERLk-AcEVSgQ5_8SzN2C2a6NzLhk8mpXmOX8=.eddc2fde-abc3-4d1a-ad6c-abe5bbb248fa@github.com>
Message-ID: <ddQIhanCyF9VyGiTDzR_mSbs9kqtbPf30SVWxcJsBUo=.3df38de9-0103-42f4-89d4-390e918049f3@github.com>

On Tue, 2 Apr 2024 17:10:18 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
>> 
>> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
>> 
>> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.
>
> Daniel Jeli?ski has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update copyright
>  - Remove comment

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18553#pullrequestreview-1974470708

From aivanov at openjdk.org  Tue Apr  2 17:30:13 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 2 Apr 2024 17:30:13 GMT
Subject: RFR: 8329340: Remove unused libawt code [v2]
In-Reply-To: <ORmg8fVATsZcMmSLeQTSwLMZrx3-Z3H0P03MLuv9mW0=.22cb8c5f-6bc1-4f90-8df7-54605accd968@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
 <LzO_Py9AfEZ6c8vZGxs6G5GG0CyA3-mVtO5QnUb7_Ms=.672bddc6-ed57-471d-99f2-c4a1c72219d1@github.com>
 <ORmg8fVATsZcMmSLeQTSwLMZrx3-Z3H0P03MLuv9mW0=.22cb8c5f-6bc1-4f90-8df7-54605accd968@github.com>
Message-ID: <WlOjuhETENVPVShBncgqpEux1awIKHHuXVAsbEfZsB4=.71a12f5d-5723-4bc4-8a00-3f81b51d16ea@github.com>

On Tue, 2 Apr 2024 16:55:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Debug.cpp line 111:
>> 
>>> 109:  * DTRACE print callback to dump window's update region bounding rectangle
>>> 110:  */
>>> 111: void DumpUpdateRectangle(const char * file, int line, int argc, const char * fmt, va_list arglist) {
>> 
>> Can these functions be useful for debugging?
>> 
>> Does it make sense to hide them unless `DEBUG` is defined?
>
> they were `if defined(DEBUG)` already; I can keep them if you think it makes sense.

I don't have any strong preference. These may be useful in rare cases where painting doesn't work as expected?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18553#discussion_r1548287746

From abhiscxk at openjdk.org  Tue Apr  2 17:32:26 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 2 Apr 2024 17:32:26 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v6]
In-Reply-To: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
Message-ID: <fj4aTlvICPicGrWDkwJcG0niBm7ZRDw4_2li8fkszKA=.a497f95e-04f3-4836-aaef-f04fe16ddfb0@github.com>

> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
> 
> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
> 
> CI link is posted 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/17720/files
  - new: https://git.openjdk.org/jdk/pull/17720/files/563be986..4a878022

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

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

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

From honkar at openjdk.org  Tue Apr  2 18:02:30 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 2 Apr 2024 18:02:30 GMT
Subject: RFR: JDK-8328753 : Open source few Undecorated Frame tests [v4]
In-Reply-To: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
Message-ID: <wTes97NO6PPgNo-DAUnWTOyTQZGkMXw8wJO1dAGrzws=.c7e3d96a-7c72-4143-85fb-bffb71671af8@github.com>

> Following tests are converted to main and open-sourced:
> 
> - /java/awt/Frame/FrameDialogMixedTest.java- Converted to main/manual using PassFailJFrame.
> - /java/awt/Frame/MaximizeUndecoratedTest.java - Automated
> - /java/awt/Frame/MinimizeUndecoratedTest.java - Automated

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

  printStackTrace, reversal of if condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18523/files
  - new: https://git.openjdk.org/jdk/pull/18523/files/9c2b2939..dad8ea8a

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

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

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

From honkar at openjdk.org  Tue Apr  2 18:02:30 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 2 Apr 2024 18:02:30 GMT
Subject: RFR: JDK-8328753 : Open source few Undecorated Frame tests [v2]
In-Reply-To: <RU8MvrHUNqzU7AH2rWRbHlfgNFr25xoqZ8nGbrxCgRI=.31e7db1e-bc95-495a-b4bf-bc0735b44cc3@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
 <KBCwA1lSI3j1IgH_Mc72T8vLYxJIaTs8JjsMLsdY2sY=.52705506-3af7-4988-94fa-5271398f1932@github.com>
 <PE5Dgy_IBGTmcNA__6qJTRSPhRLnqtgCUxYPkXOqCAc=.f6dd7d82-abdf-4942-b458-2539ea14c4c5@github.com>
 <APULaNZx8QwktRNrBPri6bedt1yzrnC9xPFv0bVN2dc=.0d2d64b4-dd06-4038-80ae-8dca78ad71d6@github.com>
 <RU8MvrHUNqzU7AH2rWRbHlfgNFr25xoqZ8nGbrxCgRI=.31e7db1e-bc95-495a-b4bf-bc0735b44cc3@github.com>
Message-ID: <E_Xs-yvXjuA2w4SidNSoyJR7gOdl1dekaPmui2EsIm8=.57a3f4b9-f907-4ac2-a833-a7836eee3857@github.com>

On Tue, 2 Apr 2024 17:06:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> It is better to re-throw it as RuntimeException. Updated.
>
>> It is better to re-throw it as RuntimeException. Updated.
> 
> Not really?
> 
> If saving the image fails, we want to preserve *the original error message* which wasn't even thrown by this time. So printing stack trace in this particular is quite safe, the exception could be ignored completely.

Good point. Updated to print stacktrace in case IOException occurs, so as to prevent masking the original more priority test exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18523#discussion_r1548326772

From honkar at openjdk.org  Tue Apr  2 18:02:30 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 2 Apr 2024 18:02:30 GMT
Subject: RFR: JDK-8328753 : Open source few Undecorated Frame tests [v3]
In-Reply-To: <2A613mykBCUuAONL-sbXDS1to3wis1DzgNpw7iaAHow=.c1ac209d-ba68-4db5-a541-af08e2c94c52@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
 <erA5EWbQxnZGfvc5qdQ5N1jT1wgrAIvQu8n-K_yiqzU=.07148e01-3211-4d6b-b50e-a745fe5e27a5@github.com>
 <2A613mykBCUuAONL-sbXDS1to3wis1DzgNpw7iaAHow=.c1ac209d-ba68-4db5-a541-af08e2c94c52@github.com>
Message-ID: <YWJroN-FOP8VbRyDcUlsChm5WZETiNMhuzbzLB2dmhY=.c0887a76-3916-43d4-8657-2405d0b8074e@github.com>

On Tue, 2 Apr 2024 17:11:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RuntimeException thrown
>
> test/jdk/java/awt/Frame/MinimizeUndecoratedTest.java line 98:
> 
>> 96:             } else {
>> 97:                 throw new RuntimeException("Window iconified event not received.");
>> 98:             }
> 
> I'd invert the condition of the `if (!isMinimized())`, then everything inside the body of the `if`-block can be unindented.

Agreed. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18523#discussion_r1548327779

From honkar at openjdk.org  Tue Apr  2 18:16:16 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 2 Apr 2024 18:16:16 GMT
Subject: Integrated: JDK-8328753 : Open source few Undecorated Frame tests
In-Reply-To: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
References: <TeT19qrHb_dsgafsfZDNyiaXEYdeOEgjJ17O6us2PTo=.228b6b55-64b4-40b4-945a-e3c25a14a393@github.com>
Message-ID: <ywQNLq_DoWELitgDTs-Gke40ISCO6j5jC3iwhgbmHzs=.d5670234-b2f3-460c-90ba-5148c3aaa9b1@github.com>

On Wed, 27 Mar 2024 17:58:06 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Following tests are converted to main and open-sourced:
> 
> - /java/awt/Frame/FrameDialogMixedTest.java- Converted to main/manual using PassFailJFrame.
> - /java/awt/Frame/MaximizeUndecoratedTest.java - Automated
> - /java/awt/Frame/MinimizeUndecoratedTest.java - Automated

This pull request has now been integrated.

Changeset: db159149
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db159149c1c13a98ee9a85750741c6a3cd39f408
Stats:     350 lines in 3 files changed: 350 ins; 0 del; 0 mod

8328753: Open source few Undecorated Frame tests

Reviewed-by: abhiscxk, dnguyen, prr, aivanov

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

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

From achung at openjdk.org  Tue Apr  2 20:58:34 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 2 Apr 2024 20:58:34 GMT
Subject: RFR: 8328648: Remove applet usage from JFileChooser tests
 bug4150029 [v9]
In-Reply-To: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
References: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
Message-ID: <aSkrKO3kF8qbFYnmIUZrX4WqRgW1HJab-2Wen7RTPXU=.bd466297-f5bc-43a9-906d-88d3697f6d54@github.com>

> Removing applet usage from manual JFileChooser tests

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

  equals modifier

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18415/files
  - new: https://git.openjdk.org/jdk/pull/18415/files/ed8ed220..358da224

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

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

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

From honkar at openjdk.org  Tue Apr  2 23:36:03 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 2 Apr 2024 23:36:03 GMT
Subject: RFR: 8328648: Remove applet usage from JFileChooser tests
 bug4150029 [v9]
In-Reply-To: <aSkrKO3kF8qbFYnmIUZrX4WqRgW1HJab-2Wen7RTPXU=.bd466297-f5bc-43a9-906d-88d3697f6d54@github.com>
References: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
 <aSkrKO3kF8qbFYnmIUZrX4WqRgW1HJab-2Wen7RTPXU=.bd466297-f5bc-43a9-906d-88d3697f6d54@github.com>
Message-ID: <ktQtxrbimMxZcAYulXjY-fx1xX6sRaDWToK6wcVDlJ4=.6991cdb1-17bc-4275-b1bc-9588c7b7a18d@github.com>

On Tue, 2 Apr 2024 20:58:34 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Removing applet usage from manual JFileChooser tests
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   equals modifier

LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18415#pullrequestreview-1975236017

From achung at openjdk.org  Tue Apr  2 23:39:11 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 2 Apr 2024 23:39:11 GMT
Subject: Integrated: 8328648: Remove applet usage from JFileChooser tests
 bug4150029
In-Reply-To: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
References: <eTiR35uGxb59RbbKcRAdTrgYkrx4CNmkIWfk63i3sJw=.8771db30-c50e-4c50-ae80-312a7683cc27@github.com>
Message-ID: <NE1v1z_jIKl8FxOwLHfpFPGOq0whovkyHARAkXREVik=.e4dc0213-8f6b-472a-9646-2fa769ac326d@github.com>

On Wed, 20 Mar 2024 22:48:46 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Removing applet usage from manual JFileChooser tests

This pull request has now been integrated.

Changeset: 021ed6ae
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/021ed6aea92f770ebeae65175d94797f7c418c82
Stats:     150 lines in 2 files changed: 55 ins; 54 del; 41 mod

8328648: Remove applet usage from JFileChooser tests bug4150029

Reviewed-by: dnguyen, abhiscxk, honkar

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

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

From ihse at openjdk.org  Wed Apr  3 00:07:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 00:07:31 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the
 Microsoft Visual C compiler
Message-ID: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>

This is a retake on https://github.com/openjdk/jdk/pull/15096.

I tried to fix the remaining issues in that PR, but could not push them. In the end, it seemed easier to create a new branch in my own personal fork.

The majority of the work in this PR has been done by @TheShermanTanker. I have stepped in and fixed the remaining comments, reverted some additional unneeded changed code, and also tried to minimize code duplication in `awt_PrintJob.cpp`.

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

Commit messages:
 - 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler

Changes: https://git.openjdk.org/jdk/pull/18584/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18584&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307160
  Stats: 428 lines in 12 files changed: 284 ins; 50 del; 94 mod
  Patch: https://git.openjdk.org/jdk/pull/18584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18584/head:pull/18584

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

From honkar at openjdk.org  Wed Apr  3 00:27:10 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 3 Apr 2024 00:27:10 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <2znFUyrPWkaar5hi-PzW4zlAVJJKoTm6ICbbfbqE254=.adbce20c-ea88-4e8f-b80f-911217e6ab8f@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
 <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
 <2znFUyrPWkaar5hi-PzW4zlAVJJKoTm6ICbbfbqE254=.adbce20c-ea88-4e8f-b80f-911217e6ab8f@github.com>
Message-ID: <eUSm1rEcXdojW3vdPfsGr4q9ZQRGjj7x_teVz-6XUp0=.aa0b9e55-5f80-4033-aaf3-7dcab1814062@github.com>

On Tue, 2 Apr 2024 04:42:12 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/java/awt/Frame/MegaIconTest/MegaIconTest.java line 194:
>> 
>>> 192:         setLayout(new BorderLayout());
>>> 193: 
>>> 194:         //Add the icon graphic and instructions to the Frame
>> 
>> The background transparency of different gifs can be checked by setting the background of the Frame to a different color.  For instance `setBackground(Color.YELLOW)` here and in the original test.
>> 
>> Adding a different background color instead of white makes it easier for the tester to compare the different types of icon.
>
> Good suggestion about setting different background Color, but here since the classes extended from one another, it would be difficult to set different background Color for each icon.

I meant setting it to one color for all icons instead of default white background at Line#.193. This makes it easier for the user to differentiate between a transparent background icon vs opaque.

You might have missed this comment as to why I suggested the above - 

> Does the test mean "icon with opaque background" by "opaque icon"? If yes, then we should use one .gif with opaque background and another with transparent background. Currently both gif files - dukeWave.gif and fight.gif, have transparent backgrounds.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1548763714

From jwaters at openjdk.org  Wed Apr  3 02:41:25 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 3 Apr 2024 02:41:25 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v70]
In-Reply-To: <H8DdyOjIYbpj5JxJDTW0-t92A9aUnY1Bquz02XWgFEk=.53238f29-59cf-4bfa-a131-cde8eae1d662@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
 <H8DdyOjIYbpj5JxJDTW0-t92A9aUnY1Bquz02XWgFEk=.53238f29-59cf-4bfa-a131-cde8eae1d662@github.com>
Message-ID: <lydTMbplYko63m30hkGIBsEOSFhk-nNYRUHjHCMIeKo=.eb608ddb-2ade-4d2a-843f-399ac171e951@github.com>

On Mon, 1 Apr 2024 10:33:41 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Labels to empty line in awt_Window.cpp
>>  - Labels to empty line in awt_Window.cpp
>>  - Label to empty line in awt_Window.cpp
>>  - Label to empty line in awt_Window.cpp
>
> Bumping

> @TheShermanTanker I tried to help you get this done. I added fixes to a copy of your branch on my personal fork, but then it turned out I could not push them to your branch. :-(
> 
> It ended up with me creating a new PR, #18584. As a bonus, I think it might be easier to review with a fresh start. This PR has grown quite heavy with lots of comments and commits.
> 
> I hope you don't feel like I'm stealing this away from you. You have done a great job, and shown a lot of patience of carrying this all the way here. But I also got the impression that you would appreciate my assistance in getting the last pieces in place so we can integrate this.

Not at all, I don't feel like you're stealing this from me. In fact, I should be the one apologising for giving you extra work! Thanks for taking this up, I once again apologise for making you do this instead, I've been very busy since Thursday (working on OpenJDK while in lectures at times), and during my breaks I've been too drained to continue, so i really appreciate your help :)

I will keep this open until the other Pull Request has been integrated, in case this might still be needed

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

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

From jwaters at openjdk.org  Wed Apr  3 02:46:59 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 3 Apr 2024 02:46:59 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler
In-Reply-To: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
References: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
Message-ID: <Pxt_yQa-pyiFUqQ5tL1M4f3WOLCNpZU2QEgH-S1qjy0=.9825ae4b-7bc0-42c7-abdb-81406c6ac295@github.com>

On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a retake on https://github.com/openjdk/jdk/pull/15096.
> 
> I tried to fix the remaining issues in that PR, but could not push them. In the end, it seemed easier to create a new branch in my own personal fork.
> 
> The majority of the work in this PR has been done by @TheShermanTanker. I have stepped in and fixed the remaining comments, reverted some additional unneeded changed code, and also tried to minimize code duplication in `awt_PrintJob.cpp`.

Looks good. Thanks for taking this up for me! In the future I hope @prrace will change his mind and allow the use of C++ Libraries in awt (awt already depends on the C++ Standard Library on Windows, verifiable if you run dumpbin -DEPENDENTS on it), because I have a change in mind relying on RAII that would look much cleaner and neater

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

Marked as reviewed by jwaters (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18584#pullrequestreview-1975384014

From ihse at openjdk.org  Wed Apr  3 08:21:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 08:21:26 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v70]
In-Reply-To: <lydTMbplYko63m30hkGIBsEOSFhk-nNYRUHjHCMIeKo=.eb608ddb-2ade-4d2a-843f-399ac171e951@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <cTyQaRQOOMA9mB8MJm2Q6IQP87QVVDJ9qvNkFX054wQ=.a555e405-571c-4490-8831-963341165a76@github.com>
 <H8DdyOjIYbpj5JxJDTW0-t92A9aUnY1Bquz02XWgFEk=.53238f29-59cf-4bfa-a131-cde8eae1d662@github.com>
 <lydTMbplYko63m30hkGIBsEOSFhk-nNYRUHjHCMIeKo=.eb608ddb-2ade-4d2a-843f-399ac171e951@github.com>
Message-ID: <499T-1pPl2Ik4W3iYBP6hOkngjUD7qINFHaf8eM8lCI=.17952ffd-d13b-4702-a350-a6aaa0963007@github.com>

On Wed, 3 Apr 2024 02:38:21 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I will keep this open until the other Pull Request has been integrated, in case this might still be needed

I don't think it is necessary. You can always re-open a PR if it should be needed, and you can look at source code and comments (and even make new comments) on a closed PR. So I think it will just make it easier for everybody if there is only a single open PR for this issue.

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

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

From psadhukhan at openjdk.org  Wed Apr  3 08:59:03 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Apr 2024 08:59:03 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v6]
In-Reply-To: <fj4aTlvICPicGrWDkwJcG0niBm7ZRDw4_2li8fkszKA=.a497f95e-04f3-4836-aaef-f04fe16ddfb0@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <fj4aTlvICPicGrWDkwJcG0niBm7ZRDw4_2li8fkszKA=.a497f95e-04f3-4836-aaef-f04fe16ddfb0@github.com>
Message-ID: <YcRcOR1PlaXZ5mozYha5wQmkmzL0F8jr9rx7KlKCOxA=.423cc4b7-d424-4fb0-99fa-176d41c850c0@github.com>

On Tue, 2 Apr 2024 17:32:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 351:

> 349:         Color caretColor = table.getColor("caretColor");
> 350:         Color controlText = table.getColor("controlText");
> 351:         Color tabbedPaneBg = new Color(238, 238, 238);

Shouldn't it be ColorUIResource?

src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java line 776:

> 774: 
> 775:         // fill content area rect for both GTK and Nimbus LAF here
> 776:         g.fillRect(x, y, w, h);

shouldn't it be within if block as is done in BasicTabbedPaneUI so that we fill only if it's opaque

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 56:

> 54:     private static final String INSTRUCTIONS = """
> 55:             The background color of panel (which contains the tabbed pane
> 56:                     is green.

instructions formatting needed..lot of empty spaces in the instruction dialog...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1549254047
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1549271306
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1549283850

From psadhukhan at openjdk.org  Wed Apr  3 09:07:12 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 3 Apr 2024 09:07:12 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <3EsEew_CjfgZsTzOyyfn_Pt8JPyLCW0wtdGeCo8iGRs=.1c3d0d8f-d375-4dc2-ab74-d5cd8d33cf13@github.com>

On Mon, 11 Mar 2024 10:05:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.

guess we need a testcase even if manual

src/java.desktop/share/classes/sun/print/PathGraphics.java line 1137:

> 1135:             return ((VolatileImage)img).getSnapshot();
> 1136:         } else if (img instanceof MultiResolutionImage) {
> 1137:             return convertToBufferedImage((MultiResolutionImage) img,

guess this casting is not needed..

src/java.desktop/share/classes/sun/print/PathGraphics.java line 1138:

> 1136:         } else if (img instanceof MultiResolutionImage) {
> 1137:             return convertToBufferedImage((MultiResolutionImage) img,
> 1138:                                            img.getWidth(null), img.getHeight(null));

Any particular reason of using getWidth/getHeight(null) as seems like in spec, this observer parameter is ignored so we can directly use getWIdth/getHeight, I presume...

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

PR Review: https://git.openjdk.org/jdk/pull/18187#pullrequestreview-1976081715
PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1549294617
PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1549296560

From ihse at openjdk.org  Wed Apr  3 10:04:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 3 Apr 2024 10:04:01 GMT
Subject: RFR: JDK-8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

The build changes look okay. 

Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-1976255818

From simon at cjnash.com  Wed Apr  3 15:35:24 2024
From: simon at cjnash.com (Simon Nash)
Date: Wed, 3 Apr 2024 16:35:24 +0100
Subject: SystemTray on Wayland with Xwayland
Message-ID: <18df915a-482a-a7c6-d66a-f4e05acf62bd@cjnash.com>

My application creates a SystemTray icon as its primary user interface. This has caused issues with some desktops (notably GNOME shell) but so far I have been
able to find workarounds for these issues.

Until now, SystemTray has worked perfectly on Raspberry Pi OS. The latest version of this (based on Debian bookworm) uses Wayland by default instead of X11. The
xwayland apt package is installed. SystemTray is not working in this environment, with SystemTray.isSupported() returning false.

There is a raspi-config option to use X11 instead of Wayland. If I select this and reboot, everything works perfectly as previously. For now, I can tell users
to do this but at some point there will be Linux distros with no option to make this change.

I have searched extensively to try to find out if this is a known issue or limitation and I haven't found anything. There is JDK-8146318 but this is very old
and seems to be a different issue.

Should it be possible to make SystemTray work with the current JDK on Wayland with xwayland by setting some system configuration? (I have tried the latest JDK
23 EA build.) If not, is there any possibility that this could be fixed by a change in the JDK?

Many thanks,
Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20240403/197df5f0/attachment.htm>

From philip.race at oracle.com  Wed Apr  3 15:53:41 2024
From: philip.race at oracle.com (Philip Race)
Date: Wed, 3 Apr 2024 08:53:41 -0700
Subject: SystemTray on Wayland with Xwayland
In-Reply-To: <18df915a-482a-a7c6-d66a-f4e05acf62bd@cjnash.com>
References: <18df915a-482a-a7c6-d66a-f4e05acf62bd@cjnash.com>
Message-ID: <f02848d4-b607-4b22-96de-5c6a65288bc3@oracle.com>

You don't say what JDK versions you are using. Nor do you say what 
version of Gnome is in use.

A number of distros started to not support the system tray by default 
requiring the user to install an extension.
As such it isn't clear that there is a long term future for what you need.
But installing that extension might be want you need to do to get it.

FYI JDK basically looks for (IIRC) an owner for the atom 
_NET_SYSTEM_TRAY to determine if there is a System Tray.

But on top of that the VERY latest JDK's like 22, the latest updates for 
21u, 17u, 11u, 8u all disable the system tray
unless you have gnome 45 or later. We were forced to do this because of 
a platform bug affecting conformance

release note here 
https://www.oracle.com/java/technologies/javase/22-relnote-issues.html

There is no way to bypass this / re-enable it because it is a 
conformance issue.

-phil.

On 4/3/24 8:35 AM, Simon Nash wrote:
> My application creates a SystemTray icon as its primary user 
> interface. This has caused issues with some desktops (notably GNOME 
> shell) but so far I have been able to find workarounds for these issues.
>
> Until now, SystemTray has worked perfectly on Raspberry Pi OS. The 
> latest version of this (based on Debian bookworm) uses Wayland by 
> default instead of X11. The xwayland apt package is installed. 
> SystemTray is not working in this environment, with 
> SystemTray.isSupported() returning false.
>
> There is a raspi-config option to use X11 instead of Wayland. If I 
> select this and reboot, everything works perfectly as previously. For 
> now, I can tell users to do this but at some point there will be Linux 
> distros with no option to make this change.
>
> I have searched extensively to try to find out if this is a known 
> issue or limitation and I haven't found anything. There is JDK-8146318 
> but this is very old and seems to be a different issue.
>
> Should it be possible to make SystemTray work with the current JDK on 
> Wayland with xwayland by setting some system configuration? (I have 
> tried the latest JDK 23 EA build.) If not, is there any possibility 
> that this could be fixed by a change in the JDK?
>
> Many thanks,
> Simon 


From tr at openjdk.org  Wed Apr  3 16:19:24 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Apr 2024 16:19:24 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v7]
In-Reply-To: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
Message-ID: <peTq82HECN-Ki6ABJNoOGuxwH83JX6UKN6Qor9PChA4=.bed6fd50-a656-4f26-91c2-11a8c00dcdc8@github.com>

> Convert and open source these manual applet test to main based:
> java/awt/Frame/MegaIconTest/MegaIconTest.html
> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
> 
> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.

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

  Reveiw updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18448/files
  - new: https://git.openjdk.org/jdk/pull/18448/files/1e9e5f28..4855b893

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

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

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

From tr at openjdk.org  Wed Apr  3 16:19:24 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 3 Apr 2024 16:19:24 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <eUSm1rEcXdojW3vdPfsGr4q9ZQRGjj7x_teVz-6XUp0=.aa0b9e55-5f80-4033-aaf3-7dcab1814062@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
 <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
 <2znFUyrPWkaar5hi-PzW4zlAVJJKoTm6ICbbfbqE254=.adbce20c-ea88-4e8f-b80f-911217e6ab8f@github.com>
 <eUSm1rEcXdojW3vdPfsGr4q9ZQRGjj7x_teVz-6XUp0=.aa0b9e55-5f80-4033-aaf3-7dcab1814062@github.com>
Message-ID: <tbKJPgccRCWLmwFyA1iGPYV7PE9Ms4qAGvhNDAF_SFs=.0a2e3280-b514-4be5-96f4-a06f83e43a59@github.com>

On Wed, 3 Apr 2024 00:18:24 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Good suggestion about setting different background Color, but here since the classes extended from one another, it would be difficult to set different background Color for each icon.
>
> I meant setting it to one color for all icons instead of default white background at Line#.193. This makes it easier for the user to differentiate between a transparent background icon vs opaque.
> 
> You might have missed this comment as to why I suggested the above - 
> 
>> Does the test mean "icon with opaque background" by "opaque icon"? If yes, then we should use one .gif with opaque background and another with transparent background. Currently both gif files - dukeWave.gif and fight.gif, have transparent backgrounds.

Yeah, had missed this point. Updated now, thanks for pointing it out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1550054450

From honkar at openjdk.org  Wed Apr  3 16:40:10 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 3 Apr 2024 16:40:10 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <tbKJPgccRCWLmwFyA1iGPYV7PE9Ms4qAGvhNDAF_SFs=.0a2e3280-b514-4be5-96f4-a06f83e43a59@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
 <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
 <2znFUyrPWkaar5hi-PzW4zlAVJJKoTm6ICbbfbqE254=.adbce20c-ea88-4e8f-b80f-911217e6ab8f@github.com>
 <eUSm1rEcXdojW3vdPfsGr4q9ZQRGjj7x_teVz-6XUp0=.aa0b9e55-5f80-4033-aaf3-7dcab1814062@github.com>
 <tbKJPgccRCWLmwFyA1iGPYV7PE9Ms4qAGvhNDAF_SFs=.0a2e3280-b514-4be5-96f4-a06f83e43a59@github.com>
Message-ID: <8f3HSrOnuzM9xatsY8SQHjiNYJuPHWsAK6_M6waAS4M=.7d818c6b-4d94-4290-ae30-310b15e52f4d@github.com>

On Wed, 3 Apr 2024 16:15:33 GMT, Tejesh R <tr at openjdk.org> wrote:

>> I meant setting it to one color for all icons instead of default white background at Line#.193. This makes it easier for the user to differentiate between a transparent background icon vs opaque.
>> 
>> You might have missed this comment as to why I suggested the above - 
>> 
>>> Does the test mean "icon with opaque background" by "opaque icon"? If yes, then we should use one .gif with opaque background and another with transparent background. Currently both gif files - dukeWave.gif and fight.gif, have transparent backgrounds.
>
> Yeah, had missed this point. Updated now, thanks for pointing it out.

This update looks good. But we still need one .gif that has opaque background.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1550086074

From psadhukhan at openjdk.org  Thu Apr  4 05:44:29 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 05:44:29 GMT
Subject: RFR: 8329559: Test javax/swing/JFrame/bug4419914.java failed because
 The End and Start buttons are not placed correctly and Tab focus does
 not move as expected
Message-ID: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>

Test issue shows the End and Start buttons are not placed as per instructions due to ComponentOrientation RTL was not honoured, as with `getContentPane()` being removed from `add` call of JFrame, it was also additionally removed from other JFrame calls which resulted in the RTL not being propagated to its child. Fix is to add `getContentPane()` to the non-add methods of JFrame as was done in the applet version of the test..

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

Commit messages:
 - 8329559: Test javax/swing/JFrame/bug4419914.java failed because The End and Start buttons are not placed correctly and Tab focus does not move as expected

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

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

From tr at openjdk.org  Thu Apr  4 06:17:37 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 06:17:37 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v8]
In-Reply-To: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
Message-ID: <nHzzxcYsKEQHbAlKr4iIymTsiKHsOlP6lhlVDjUFYOE=.eb1ad404-cbff-4383-970b-3ddfc8b68561@github.com>

> Convert and open source these manual applet test to main based:
> java/awt/Frame/MegaIconTest/MegaIconTest.html
> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
> 
> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.

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

  Added opaque image

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18448/files
  - new: https://git.openjdk.org/jdk/pull/18448/files/4855b893..691fa6fe

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

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

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

From tr at openjdk.org  Thu Apr  4 06:17:37 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 06:17:37 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v5]
In-Reply-To: <8f3HSrOnuzM9xatsY8SQHjiNYJuPHWsAK6_M6waAS4M=.7d818c6b-4d94-4290-ae30-310b15e52f4d@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <Ag3ABER1d_aho3spUx8KmIbJPiggpNrTC8P62NHLzew=.5cfb4df3-2c17-4c8b-900d-976c51223d6d@github.com>
 <JNBnXa-kQnJqxIzbqMNcKiLyaOu3y1BC_c-lrhxcvAc=.24fe9175-fcb8-40bf-aef5-e1bfea46705a@github.com>
 <2znFUyrPWkaar5hi-PzW4zlAVJJKoTm6ICbbfbqE254=.adbce20c-ea88-4e8f-b80f-911217e6ab8f@github.com>
 <eUSm1rEcXdojW3vdPfsGr4q9ZQRGjj7x_teVz-6XUp0=.aa0b9e55-5f80-4033-aaf3-7dcab1814062@github.com>
 <tbKJPgccRCWLmwFyA1iGPYV7PE9Ms4qAGvhNDAF_SFs=.0a2e3280-b514-4be5-96f4-a06f83e43a59@github.com>
 <8f3HSrOnuzM9xatsY8SQHjiNYJuPHWsAK6_M6waAS4M=.7d818c6b-4d94-4290-ae30-310b15e52f4d@github.com>
Message-ID: <ZHRDNQbQX4Ya5jNwnzk0oYoqAQi9jdZvML06gWZRU80=.cc9707b9-8814-4e09-b27a-5d8a8469d7bd@github.com>

On Wed, 3 Apr 2024 16:37:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Yeah, had missed this point. Updated now, thanks for pointing it out.
>
> This update looks good. But we still need one .gif that has opaque background. Currently both the .gif have transparent background.
> 
> ![image](https://github.com/openjdk/jdk/assets/95945681/4f01269e-e76d-4ab6-a24f-cec3be3c4ad7)

Yeah, updated with opaque image, `duke_404.gif`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1550986566

From abhiscxk at openjdk.org  Thu Apr  4 06:55:29 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Apr 2024 06:55:29 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
Message-ID: <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>

> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
> 
> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
> 
> CI link is posted in JBS.

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

  Review comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17720/files
  - new: https://git.openjdk.org/jdk/pull/17720/files/4a878022..250fe3af

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

  Stats: 20 lines in 3 files changed: 2 ins; 6 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/17720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17720/head:pull/17720

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

From abhiscxk at openjdk.org  Thu Apr  4 06:55:29 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Apr 2024 06:55:29 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v6]
In-Reply-To: <YcRcOR1PlaXZ5mozYha5wQmkmzL0F8jr9rx7KlKCOxA=.423cc4b7-d424-4fb0-99fa-176d41c850c0@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <fj4aTlvICPicGrWDkwJcG0niBm7ZRDw4_2li8fkszKA=.a497f95e-04f3-4836-aaef-f04fe16ddfb0@github.com>
 <YcRcOR1PlaXZ5mozYha5wQmkmzL0F8jr9rx7KlKCOxA=.423cc4b7-d424-4fb0-99fa-176d41c850c0@github.com>
Message-ID: <WgNHr40dGipm9_eN_8Sl3BtV_Vp_GNsNBbCryls5Ixg=.8a3cefce-53e7-405c-8c27-d6514edcd79f@github.com>

On Wed, 3 Apr 2024 08:38:38 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 351:
> 
>> 349:         Color caretColor = table.getColor("caretColor");
>> 350:         Color controlText = table.getColor("controlText");
>> 351:         Color tabbedPaneBg = new Color(238, 238, 238);
> 
> Shouldn't it be ColorUIResource?

Updated.

> src/java.desktop/share/classes/javax/swing/plaf/synth/SynthTabbedPaneUI.java line 776:
> 
>> 774: 
>> 775:         // fill content area rect for both GTK and Nimbus LAF here
>> 776:         g.fillRect(x, y, w, h);
> 
> shouldn't it be within if block as is done in BasicTabbedPaneUI so that we fill only if it's opaque

Yes.. updated now.

> test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 56:
> 
>> 54:     private static final String INSTRUCTIONS = """
>> 55:             The background color of panel (which contains the tabbed pane
>> 56:                     is green.
> 
> instructions formatting needed..lot of empty spaces in the instruction dialog...

Updated now... seems ok to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1551025037
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1551025218
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1551025490

From abhiscxk at openjdk.org  Thu Apr  4 07:11:59 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Apr 2024 07:11:59 GMT
Subject: RFR: 8329559: Test javax/swing/JFrame/bug4419914.java failed
 because The End and Start buttons are not placed correctly and Tab focus does
 not move as expected
In-Reply-To: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>
References: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>
Message-ID: <8AYg1iHS6Vrx_OUbwtQqOB_sHIzt7ykVZEEAXJwkNaA=.250e9a86-21ed-4241-bddf-cdf4df9811ec@github.com>

On Thu, 4 Apr 2024 05:34:18 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test issue shows the End and Start buttons are not placed as per instructions due to ComponentOrientation RTL was not honoured, as with `getContentPane()` being removed from `add` call of JFrame, it was also additionally removed from other JFrame calls which resulted in the RTL not being propagated to its child. Fix is to add `getContentPane()` to the non-add methods of JFrame as was done in the applet version of the test..

Just a minor suggestion, can increase the row count to avoid the scrollbar else looks good to me.

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

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18612#pullrequestreview-1978915124

From tr at openjdk.org  Thu Apr  4 07:13:10 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 07:13:10 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <3EsEew_CjfgZsTzOyyfn_Pt8JPyLCW0wtdGeCo8iGRs=.1c3d0d8f-d375-4dc2-ab74-d5cd8d33cf13@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <3EsEew_CjfgZsTzOyyfn_Pt8JPyLCW0wtdGeCo8iGRs=.1c3d0d8f-d375-4dc2-ab74-d5cd8d33cf13@github.com>
Message-ID: <Y8pMogHfW2lLHvRUbZ3PBG6TEX3uGPox_ZmpTZDJ8IU=.053e95f2-8cfe-4c28-9927-77ae81144096@github.com>

On Wed, 3 Apr 2024 09:01:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.
>
> src/java.desktop/share/classes/sun/print/PathGraphics.java line 1137:
> 
>> 1135:             return ((VolatileImage)img).getSnapshot();
>> 1136:         } else if (img instanceof MultiResolutionImage) {
>> 1137:             return convertToBufferedImage((MultiResolutionImage) img,
> 
> guess this casting is not needed..

It is required, without casting it throws `incompatible type error`.

> src/java.desktop/share/classes/sun/print/PathGraphics.java line 1138:
> 
>> 1136:         } else if (img instanceof MultiResolutionImage) {
>> 1137:             return convertToBufferedImage((MultiResolutionImage) img,
>> 1138:                                            img.getWidth(null), img.getHeight(null));
> 
> Any particular reason of using getWidth/getHeight(null) as seems like in spec, this observer parameter is ignored so we can directly use getWIdth/getHeight, I presume...

No, we have to pass null if the parameter is ignored. Without it we will get error.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1551047672
PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1551048929

From abhiscxk at openjdk.org  Thu Apr  4 07:48:02 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Apr 2024 07:48:02 GMT
Subject: RFR: 8329510: Update ProblemList for
 JFileChooser/8194044/FileSystemRootTest.java
In-Reply-To: <QDbaHbypmsltrQkLn_jhQsVvu3syniL6tkPYczy7rVs=.9f78e299-ad12-40f4-a89f-976ad5e6e1be@github.com>
References: <QDbaHbypmsltrQkLn_jhQsVvu3syniL6tkPYczy7rVs=.9f78e299-ad12-40f4-a89f-976ad5e6e1be@github.com>
Message-ID: <HeClW_iCZ9EA4SMIYNkG7FY2TnhcGs0V7g1Q9dgiOuI=.2134e231-9790-4806-9257-2fe7460bbc60@github.com>

On Tue, 2 Apr 2024 10:29:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the problem-list entry for ` javax/swing/JFileChooser/8194044/FileSystemRootTest.java` to refer to [JDK-8327236](https://bugs.openjdk.org/browse/JDK-8327236) under which the failure with `"root drive reported as false"` is tracked.

Marked as reviewed by abhiscxk (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18580#pullrequestreview-1978994495

From abhiscxk at openjdk.org  Thu Apr  4 07:50:12 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Apr 2024 07:50:12 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <uSDZ5s3eE0i_L4Yst5KapYvBK8lGVvGt9MvFrjS9NQs=.24780273-f30a-4b25-91a7-dab2c21448e7@github.com>

On Mon, 11 Mar 2024 10:05:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue introduced in 22, yet to investigate on it).

Better if you specify the JBS issue link in the description.

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2036429931

From psadhukhan at openjdk.org  Thu Apr  4 09:15:00 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 09:15:00 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>

On Mon, 11 Mar 2024 10:05:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.

Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F
Also, you need to add this bugid to the test

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2036619933

From psadhukhan at openjdk.org  Thu Apr  4 09:38:20 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 09:38:20 GMT
Subject: RFR: 8329559: Test javax/swing/JFrame/bug4419914.java failed
 because The End and Start buttons are not placed correctly and Tab focus does
 not move as expected [v2]
In-Reply-To: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>
References: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>
Message-ID: <D1KA3JdD9qQ4HW5IOrXIpw_B22yxJGegx55Nj4tZsJ0=.2e4709c4-8b18-412f-82be-a2cf92df188e@github.com>

> Test issue shows the End and Start buttons are not placed as per instructions due to ComponentOrientation RTL was not honoured, as with `getContentPane()` being removed from `add` call of JFrame, it was also additionally removed from other JFrame calls which resulted in the RTL not being propagated to its child. Fix is to add `getContentPane()` to the non-add methods of JFrame as was done in the applet version of the test..

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

  instruction formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18612/files
  - new: https://git.openjdk.org/jdk/pull/18612/files/61a0a049..79123987

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

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

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

From tr at openjdk.org  Thu Apr  4 09:58:10 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 09:58:10 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
Message-ID: <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>

On Thu, 4 Apr 2024 09:12:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test

The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus. Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2036727358

From tr at openjdk.org  Thu Apr  4 10:01:09 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 10:01:09 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <fbgjHTfX0xNLv-muIQemhIDjsjqqQeZno0HAJ1xBQVU=.0a3ce944-9649-428d-9358-e00155dfd0c6@github.com>

On Mon, 11 Mar 2024 10:05:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.

> > Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test
> 
> The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus (Since in Nimbus SunGraphics2D was handling Image drawing where I proposed a fix to retain PathGraphics, hence casued regression for Nimbus). Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2036733899

From tr at openjdk.org  Thu Apr  4 10:35:22 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 10:35:22 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel [v2]
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <WdIr-XJAfVq7KOMVFjJfj7ObW-itoexFlcd75x302EE=.c1f35956-1e62-4c51-8d14-c13a2cf7c758@github.com>

> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.

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

 - Spacing updates
 - Updated test with BugID and copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18187/files
  - new: https://git.openjdk.org/jdk/pull/18187/files/38bbbe75..41fcb586

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

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

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

From psadhukhan at openjdk.org  Thu Apr  4 11:18:10 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 11:18:10 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
 <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>
Message-ID: <nXyBZE8rT0f9LsGliZ-BqMZ8AdHurLpNL1_SusHeuCY=.54952fd6-5bba-46e4-8b1a-819dd8fc0ec8@github.com>

On Thu, 4 Apr 2024 09:55:27 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test
> 
> The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus. Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).

I guess the PathGraphics path should be used for printing images and should be common for all so why Nimbus is going via SunGraphics2D? [and it seems you updated the summary to include Aqua so Aqua is also going via SunGraphics2D?]

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2036881285

From tr at openjdk.org  Thu Apr  4 11:33:00 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 11:33:00 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <nXyBZE8rT0f9LsGliZ-BqMZ8AdHurLpNL1_SusHeuCY=.54952fd6-5bba-46e4-8b1a-819dd8fc0ec8@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
 <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>
 <nXyBZE8rT0f9LsGliZ-BqMZ8AdHurLpNL1_SusHeuCY=.54952fd6-5bba-46e4-8b1a-819dd8fc0ec8@github.com>
Message-ID: <sDXCd9U_Gcvaiaa83YTJKQJkgJwwWXDV4fbGjj1aEOo=.092199bf-39eb-43b7-89a0-f7fa3913a7b5@github.com>

On Thu, 4 Apr 2024 11:15:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test
> > 
> > 
> > The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus. Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).
> 
> I guess the PathGraphics path should be used for printing images and should be common for all so why Nimbus is going via SunGraphics2D? [and it seems you updated the summary to include Aqua so Aqua is also going via SunGraphics2D?]

Yes, the issue is found in Aqua also and that too uses SunGraphics2D. And regarding why SunGraphics2D is used for Nimbus and Aqua, its because in Nimbus PeekGraphics is used which in-turn useses SunGraphics2D and in other its PW/WPathGraphics. I'm not sure why this is different.

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2036917767

From psadhukhan at openjdk.org  Thu Apr  4 11:44:01 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 11:44:01 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <sDXCd9U_Gcvaiaa83YTJKQJkgJwwWXDV4fbGjj1aEOo=.092199bf-39eb-43b7-89a0-f7fa3913a7b5@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
 <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>
 <nXyBZE8rT0f9LsGliZ-BqMZ8AdHurLpNL1_SusHeuCY=.54952fd6-5bba-46e4-8b1a-819dd8fc0ec8@github.com>
 <sDXCd9U_Gcvaiaa83YTJKQJkgJwwWXDV4fbGjj1aEOo=.092199bf-39eb-43b7-89a0-f7fa3913a7b5@github.com>
Message-ID: <Ip0JayogCimkItLvNzyUbDFQ6o8y6R_BUqVF3YWqgyc=.e6bcf597-fd41-4c75-ae54-872c8c4ab140@github.com>

On Thu, 4 Apr 2024 11:30:14 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > > Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test
> > > 
> > > 
> > > The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus. Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).
> > 
> > 
> > I guess the PathGraphics path should be used for printing images and should be common for all so why Nimbus is going via SunGraphics2D? [and it seems you updated the summary to include Aqua so Aqua is also going via SunGraphics2D?]
> 
> Yes, the issue is found in Aqua also and that too uses SunGraphics2D. And regarding why SunGraphics2D is used for Nimbus and Aqua, its because in Nimbus PeekGraphics is used which in-turn useses SunGraphics2D and in other its PW/WPathGraphics. I'm not sure why this is different.

Can you point to the code where it uses PeekGraphics in Nimbus/Aqua and the subsequent code from where is starts to bifurcate in other L&F meaning where it starts to uses PeekGraphics for Nimbus/Aqua and PathGraphics for others?

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2036938917

From abhiscxk at openjdk.org  Thu Apr  4 11:45:10 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Apr 2024 11:45:10 GMT
Subject: RFR: 8329559: Test javax/swing/JFrame/bug4419914.java failed
 because The End and Start buttons are not placed correctly and Tab focus does
 not move as expected [v2]
In-Reply-To: <D1KA3JdD9qQ4HW5IOrXIpw_B22yxJGegx55Nj4tZsJ0=.2e4709c4-8b18-412f-82be-a2cf92df188e@github.com>
References: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>
 <D1KA3JdD9qQ4HW5IOrXIpw_B22yxJGegx55Nj4tZsJ0=.2e4709c4-8b18-412f-82be-a2cf92df188e@github.com>
Message-ID: <WgV3apeW4gaKGwVKN-oRIQTjQcDfPdgJHmX-h7sh8PM=.6331ad6d-2ac5-4555-b3fe-43f767b89a9a@github.com>

On Thu, 4 Apr 2024 09:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test issue shows the End and Start buttons are not placed as per instructions due to ComponentOrientation RTL was not honoured, as with `getContentPane()` being removed from `add` call of JFrame, it was also additionally removed from other JFrame calls which resulted in the RTL not being propagated to its child. Fix is to add `getContentPane()` to the non-add methods of JFrame as was done in the applet version of the test..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   instruction formatting

Marked as reviewed by abhiscxk (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18612#pullrequestreview-1979619565

From psadhukhan at openjdk.org  Thu Apr  4 12:07:18 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 12:07:18 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
Message-ID: <5s7eNsEBN6MAuwzCFTVJ5hfvbblPhmwtTDNvTiG_8wI=.7f3e38e9-751e-40b3-98b9-6f73fd4cbc61@github.com>

On Thu, 4 Apr 2024 06:55:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 21653:

> 21651:                <uiProperty name="useBasicArrows" type="BOOLEAN" value="true"/>
> 21652:                <uiProperty name="contentOpaque" type="BOOLEAN" value="true"/>
> 21653:                <uiProperty name="contentAreaColor" type="COLOR">

SInce you are introducing those 3 property in NimbusLookANdFeel, is this defines needed in skin.laf?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1551543921

From rkannathpari at openjdk.org  Thu Apr  4 12:13:17 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 4 Apr 2024 12:13:17 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use PassFailJFrame
Message-ID: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>

Hi Reviewers,

I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.

Renjith.

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

Commit messages:
 - JDK-8329322:Convert PageFormat/Orient.java to use PassFailJFrame

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

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

From abhiscxk at openjdk.org  Thu Apr  4 12:31:12 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 4 Apr 2024 12:31:12 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <5s7eNsEBN6MAuwzCFTVJ5hfvbblPhmwtTDNvTiG_8wI=.7f3e38e9-751e-40b3-98b9-6f73fd4cbc61@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
 <5s7eNsEBN6MAuwzCFTVJ5hfvbblPhmwtTDNvTiG_8wI=.7f3e38e9-751e-40b3-98b9-6f73fd4cbc61@github.com>
Message-ID: <cJ9hwWEBm2o-NI3fqI4YnaZI02FApQjKKzHPLkEoD1E=.8c9af358-0984-4b17-84fe-47779cfa5b3c@github.com>

On Thu, 4 Apr 2024 12:04:12 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 21653:
> 
>> 21651:                <uiProperty name="useBasicArrows" type="BOOLEAN" value="true"/>
>> 21652:                <uiProperty name="contentOpaque" type="BOOLEAN" value="true"/>
>> 21653:                <uiProperty name="contentAreaColor" type="COLOR">
> 
> SInce you are introducing those 3 property in NimbusLookANdFeel, is this defines needed in skin.laf?

I am not sure about this. Should I add them in skin.laf ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1551585863

From tr at openjdk.org  Thu Apr  4 14:46:10 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 14:46:10 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <Ip0JayogCimkItLvNzyUbDFQ6o8y6R_BUqVF3YWqgyc=.e6bcf597-fd41-4c75-ae54-872c8c4ab140@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
 <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>
 <nXyBZE8rT0f9LsGliZ-BqMZ8AdHurLpNL1_SusHeuCY=.54952fd6-5bba-46e4-8b1a-819dd8fc0ec8@github.com>
 <sDXCd9U_Gcvaiaa83YTJKQJkgJwwWXDV4fbGjj1aEOo=.092199bf-39eb-43b7-89a0-f7fa3913a7b5@github.com>
 <Ip0JayogCimkItLvNzyUbDFQ6o8y6R_BUqVF3YWqgyc=.e6bcf597-fd41-4c75-ae54-872c8c4ab140@github.com>
Message-ID: <IXftVfnWisE5x9951KLLKhkoPbFXysdtR_yLYM4Wuic=.42a7fed8-70e4-44d7-a7ce-6d746d1d4bfd@github.com>

On Thu, 4 Apr 2024 11:41:25 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > > Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test
> > > > 
> > > > 
> > > > The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus. Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).
> > > 
> > > 
> > > I guess the PathGraphics path should be used for printing images and should be common for all so why Nimbus is going via SunGraphics2D? [and it seems you updated the summary to include Aqua so Aqua is also going via SunGraphics2D?]
> > 
> > 
> > Yes, the issue is found in Aqua also and that too uses SunGraphics2D. And regarding why SunGraphics2D is used for Nimbus and Aqua, its because in Nimbus PeekGraphics is used which in-turn useses SunGraphics2D and in other its PW/WPathGraphics. I'm not sure why this is different.
> 
> Can you point to the code where it uses PeekGraphics in Nimbus/Aqua and the subsequent code from where is starts to bifurcate in other L&F meaning where it starts to uses PeekGraphics for Nimbus/Aqua and PathGraphics for others?

Yeah, it is from RasterPrinterJob class [here](https://github.com/openjdk/jdk/blob/21867c929a2f2c961148f2cd1e79d672ac278d27/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L2298). And that is because of nonSolidColors present in Nimbus and Aqua L&F.

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2037409936

From tr at openjdk.org  Thu Apr  4 17:05:44 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 17:05:44 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v8]
In-Reply-To: <nHzzxcYsKEQHbAlKr4iIymTsiKHsOlP6lhlVDjUFYOE=.eb1ad404-cbff-4383-970b-3ddfc8b68561@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <nHzzxcYsKEQHbAlKr4iIymTsiKHsOlP6lhlVDjUFYOE=.eb1ad404-cbff-4383-970b-3ddfc8b68561@github.com>
Message-ID: <OxMwA979_aWIhDNmNBCL6duJZWgutamoowUD7ISG3AM=.c2bae2d7-2df5-4536-b516-497b46777ba6@github.com>

On Thu, 4 Apr 2024 06:17:37 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Convert and open source these manual applet test to main based:
>> java/awt/Frame/MegaIconTest/MegaIconTest.html
>> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
>> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
>> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
>> 
>> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added opaque image

@honkar-jdk  Thank you for your inputs and suggestions. I have updated the test with ICONIFIED state and with `windowStateChanged` event.

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

PR Comment: https://git.openjdk.org/jdk/pull/18448#issuecomment-2037733356

From tr at openjdk.org  Thu Apr  4 17:05:44 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 4 Apr 2024 17:05:44 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v9]
In-Reply-To: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
Message-ID: <p4d9dKurkPN0gA1BfZYzcTSzgB2evHWQubSGuolaXgo=.1ad3228e-c41a-497a-b0ef-4eebc7cb339d@github.com>

> Convert and open source these manual applet test to main based:
> java/awt/Frame/MegaIconTest/MegaIconTest.html
> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
> 
> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.

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

  Review comments updated - SizeMinimizedTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18448/files
  - new: https://git.openjdk.org/jdk/pull/18448/files/691fa6fe..93a24977

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

  Stats: 50 lines in 1 file changed: 23 ins; 17 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18448/head:pull/18448

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

From psadhukhan at openjdk.org  Thu Apr  4 17:21:04 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 17:21:04 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <IXftVfnWisE5x9951KLLKhkoPbFXysdtR_yLYM4Wuic=.42a7fed8-70e4-44d7-a7ce-6d746d1d4bfd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
 <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>
 <nXyBZE8rT0f9LsGliZ-BqMZ8AdHurLpNL1_SusHeuCY=.54952fd6-5bba-46e4-8b1a-819dd8fc0ec8@github.com>
 <sDXCd9U_Gcvaiaa83YTJKQJkgJwwWXDV4fbGjj1aEOo=.092199bf-39eb-43b7-89a0-f7fa3913a7b5@github.com>
 <Ip0JayogCimkItLvNzyUbDFQ6o8y6R_BUqVF3YWqgyc=.e6bcf597-fd41-4c75-ae54-872c8c4ab140@github.com>
 <IXftVfnWisE5x9951KLLKhkoPbFXysdtR_yLYM4Wuic=.42a7fed8-70e4-44d7-a7ce-6d746d1d4bfd@github.com>
Message-ID: <vlZ8eKbOk2wcvSOKTp97ny4sFDFtsJoMU7CmFfmHBuI=.d51febf3-fade-4436-8f22-c4826f2c76e0@github.com>

On Thu, 4 Apr 2024 14:43:43 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > > > > Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test
> > > > > 
> > > > > 
> > > > > The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus. Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).
> > > > 
> > > > 
> > > > I guess the PathGraphics path should be used for printing images and should be common for all so why Nimbus is going via SunGraphics2D? [and it seems you updated the summary to include Aqua so Aqua is also going via SunGraphics2D?]
> > > 
> > > 
> > > Yes, the issue is found in Aqua also and that too uses SunGraphics2D. And regarding why SunGraphics2D is used for Nimbus and Aqua, its because in Nimbus PeekGraphics is used which in-turn useses SunGraphics2D and in other its PW/WPathGraphics. I'm not sure why this is different.
> > 
> > 
> > Can you point to the code where it uses PeekGraphics in Nimbus/Aqua and the subsequent code from where is starts to bifurcate in other L&F meaning where it starts to uses PeekGraphics for Nimbus/Aqua and PathGraphics for others?
> 
> Yeah, it is from RasterPrinterJob class [here](https://github.com/openjdk/jdk/blob/21867c929a2f2c961148f2cd1e79d672ac278d27/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L2298). And that is because of nonSolidColors present in Nimbus and Aqua L&F.

I didn't get how it creates PeekGraphics for Nimbus/Aqua and PathGraphics for others? I guess RasterPrinterJob will delegate to WPrinterJob in windows and PSPrinterJob in unix and it is not dependant on L&F...

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2037768402

From psadhukhan at openjdk.org  Thu Apr  4 17:23:10 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 17:23:10 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
Message-ID: <AiDLz1rlEahkR-9yVHchm5VOU4MwqLHv0XMU4vwEJbo=.8ad84fc2-4a97-4b88-844d-a29f6322117e@github.com>

On Thu, 4 Apr 2024 06:55:29 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 1026:

> 1024:             "TabbedPane.selected", tabbedPaneBg,
> 1025:             "TabbedPane.contentOpaque", Boolean.TRUE,
> 1026:             "TabbedPane.contentAreaColor", tabbedPaneBg,

`TabbedPane.contentOpaque` and `TabbedPane.tabsOpaque` seems to go hand-in-hand and there's another issue for it https://bugs.openjdk.org/browse/JDK-6462396 so if we are supporting one and not other, it may not have desired effect..

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1552103661

From psadhukhan at openjdk.org  Thu Apr  4 17:23:11 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 4 Apr 2024 17:23:11 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <cJ9hwWEBm2o-NI3fqI4YnaZI02FApQjKKzHPLkEoD1E=.8c9af358-0984-4b17-84fe-47779cfa5b3c@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
 <5s7eNsEBN6MAuwzCFTVJ5hfvbblPhmwtTDNvTiG_8wI=.7f3e38e9-751e-40b3-98b9-6f73fd4cbc61@github.com>
 <cJ9hwWEBm2o-NI3fqI4YnaZI02FApQjKKzHPLkEoD1E=.8c9af358-0984-4b17-84fe-47779cfa5b3c@github.com>
Message-ID: <_-xzgTiORLrtIpAWxaSTmDGhwB8XA1Z5y8gS9uFPfQo=.e3ddeefe-c724-4123-ba8b-73c73f60891b@github.com>

On Thu, 4 Apr 2024 12:28:36 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/plaf/nimbus/skin.laf line 21653:
>> 
>>> 21651:                <uiProperty name="useBasicArrows" type="BOOLEAN" value="true"/>
>>> 21652:                <uiProperty name="contentOpaque" type="BOOLEAN" value="true"/>
>>> 21653:                <uiProperty name="contentAreaColor" type="COLOR">
>> 
>> SInce you are introducing those 3 property in NimbusLookANdFeel, is this defines needed in skin.laf?
>
> I am not sure about this. Should I add them in skin.laf ?

you have already added...i am asking it it's needed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1552104159

From honkar at openjdk.org  Thu Apr  4 17:42:13 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 4 Apr 2024 17:42:13 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v9]
In-Reply-To: <p4d9dKurkPN0gA1BfZYzcTSzgB2evHWQubSGuolaXgo=.1ad3228e-c41a-497a-b0ef-4eebc7cb339d@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <p4d9dKurkPN0gA1BfZYzcTSzgB2evHWQubSGuolaXgo=.1ad3228e-c41a-497a-b0ef-4eebc7cb339d@github.com>
Message-ID: <5258N78r8_XvKYWtr_q-G8iv1qVr6fuMS1wIhfWKL7o=.08f42753-4a29-4242-8bde-719dc3277365@github.com>

On Thu, 4 Apr 2024 17:05:44 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Convert and open source these manual applet test to main based:
>> java/awt/Frame/MegaIconTest/MegaIconTest.html
>> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
>> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
>> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
>> 
>> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments updated - SizeMinimizedTest

Changes requested by honkar (Reviewer).

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 37:

> 35:  * @bug 4065534
> 36:  * @summary Frame.setSize() doesn't change size if window is in an iconified state
> 37:  * @run main/manual SizeMinimizedTest

manual should be removed since it is automated now. 
Does CI Testing look good with the updated test changes?

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 43:

> 41:     private static Frame frame;
> 42:     private static final int INITIAL_WIDTH = 100;
> 43:     private static final int INITIAL_HEIGHT = 100;

Instead of defining width and height separately you can re-use the same constant by defining it as INITIAL_SIZE.
Suggestion:

    private static final int INITIAL_SIZE = 100;

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 47:

> 45:     private static final int INITIAL_Y = 50;
> 46:     private static final int RESET_WIDTH = 200;
> 47:     private static final int RESET_HEIGHT = 200;

Same here, can be renamed as one single constant RESET_SIZE.

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 58:

> 56:         Robot robot = new Robot();
> 57:         try {
> 58:             frame = new Frame("frame size test");

Suggestion:

            frame = new Frame("Frame size test");

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 69:

> 67:                     System.out.println("Initial Frame Location: " + frame.getLocationOnScreen());
> 68:                 }
> 69:             });

This windowlistener should be added before `frame.setVisible(true);` else the initial frame size and location are not logged. 
Moving the creation of UI to a separate method (eg. createUI) makes the code cleaner.

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 84:

> 82:                         }
> 83: 
> 84:                         expectedLoc = new Point(INITIAL_X + OFFSET * iterationCnt, INITIAL_Y);

Please fix line-lengths.

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

PR Review: https://git.openjdk.org/jdk/pull/18448#pullrequestreview-1980668081
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552117771
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552120607
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552121767
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552123280
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552134912
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552140246

From mikael at openjdk.org  Thu Apr  4 20:54:34 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 4 Apr 2024 20:54:34 GMT
Subject: RFR: 8329703: Remove unused apple.jpeg file from SwingSet2 demo
Message-ID: <zcFqZ_fjtBGnbKNXaAylo9wSAtbp7oWvs6J1XfvQteE=.728982f5-c58e-496b-afcf-7fe54daa203f@github.com>

The following two files have the exact same contents:

src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpg
src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpeg

Only the first one is actually used in the demo. The latter is unused and should be deleted.

Testing: tier1 + verified that Robi Khan still has a beautiful looking apple as their favorite food in the demo

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

Commit messages:
 - 8329703: Remove unused apple.jpeg file from SwingSet2 demo

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

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

From prr at openjdk.org  Thu Apr  4 21:31:02 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Apr 2024 21:31:02 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler
In-Reply-To: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
References: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
Message-ID: <RN5hrg_UrG7Q71wlRtMLI9wtJCB70ShmqycWbZrkKjQ=.79dad1d4-3bc7-4779-a2dd-7d42c00c1197@github.com>

On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a retake on https://github.com/openjdk/jdk/pull/15096.
> 
> I tried to fix the remaining issues in that PR, but could not push them. In the end, it seemed easier to create a new branch in my own personal fork.
> 
> The majority of the work in this PR has been done by @TheShermanTanker. I have stepped in and fixed the remaining comments, reverted some additional unneeded changed code, and also tried to minimize code duplication in `awt_PrintJob.cpp`.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18584#pullrequestreview-1981217028

From prr at openjdk.org  Thu Apr  4 21:31:02 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 4 Apr 2024 21:31:02 GMT
Subject: RFR: 8329703: Remove unused apple.jpeg file from SwingSet2 demo
In-Reply-To: <zcFqZ_fjtBGnbKNXaAylo9wSAtbp7oWvs6J1XfvQteE=.728982f5-c58e-496b-afcf-7fe54daa203f@github.com>
References: <zcFqZ_fjtBGnbKNXaAylo9wSAtbp7oWvs6J1XfvQteE=.728982f5-c58e-496b-afcf-7fe54daa203f@github.com>
Message-ID: <ELv20AYHNzzR7OAH2vQDvmYSgdy8-tCuZdGredPdnk4=.aa670e64-8068-498f-9e52-3cc877a0b16b@github.com>

On Thu, 4 Apr 2024 19:29:48 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The following two files have the exact same contents:
> 
> src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpg
> src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpeg
> 
> Only the first one is actually used in the demo. The latter is unused and should be deleted.
> 
> Testing: tier1 + verified that Robi Khan still has a beautiful looking apple as their favorite food in the demo

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18635#pullrequestreview-1981218507

From mikael at openjdk.org  Thu Apr  4 21:35:12 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 4 Apr 2024 21:35:12 GMT
Subject: RFR: 8329703: Remove unused apple.jpeg file from SwingSet2 demo
In-Reply-To: <zcFqZ_fjtBGnbKNXaAylo9wSAtbp7oWvs6J1XfvQteE=.728982f5-c58e-496b-afcf-7fe54daa203f@github.com>
References: <zcFqZ_fjtBGnbKNXaAylo9wSAtbp7oWvs6J1XfvQteE=.728982f5-c58e-496b-afcf-7fe54daa203f@github.com>
Message-ID: <LItc_NlWyCPGsKex9pFChhaRK95EfumlREFzKWZ7l8U=.0c3f03b7-be78-410a-8c74-5b5b0180fe51@github.com>

On Thu, 4 Apr 2024 19:29:48 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The following two files have the exact same contents:
> 
> src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpg
> src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpeg
> 
> Only the first one is actually used in the demo. The latter is unused and should be deleted.
> 
> Testing: tier1 + verified that Robi Khan still has a beautiful looking apple as their favorite food in the demo

Thank you for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/18635#issuecomment-2038265649

From mikael at openjdk.org  Thu Apr  4 21:35:12 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Thu, 4 Apr 2024 21:35:12 GMT
Subject: Integrated: 8329703: Remove unused apple.jpeg file from SwingSet2 demo
In-Reply-To: <zcFqZ_fjtBGnbKNXaAylo9wSAtbp7oWvs6J1XfvQteE=.728982f5-c58e-496b-afcf-7fe54daa203f@github.com>
References: <zcFqZ_fjtBGnbKNXaAylo9wSAtbp7oWvs6J1XfvQteE=.728982f5-c58e-496b-afcf-7fe54daa203f@github.com>
Message-ID: <fH56l0QptC4n93z8fRC1QxR31DTUCY7w8s2ZQltu4k4=.0784cfa5-b578-4539-91c4-d8f49986eb67@github.com>

On Thu, 4 Apr 2024 19:29:48 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

> The following two files have the exact same contents:
> 
> src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpg
> src/demo/share/jfc/SwingSet2/resources/images/food/apple.jpeg
> 
> Only the first one is actually used in the demo. The latter is unused and should be deleted.
> 
> Testing: tier1 + verified that Robi Khan still has a beautiful looking apple as their favorite food in the demo

This pull request has now been integrated.

Changeset: e1183ac0
Author:    Mikael Vidstedt <mikael at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1183ac044f803bf0d4ccfebc2b1cd5b33294c7a
Stats:     0 lines in 1 file changed: 0 ins; 0 del; 0 mod

8329703: Remove unused apple.jpeg file from SwingSet2 demo

Reviewed-by: prr

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

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

From ihse at openjdk.org  Thu Apr  4 22:47:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 4 Apr 2024 22:47:18 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v2]
In-Reply-To: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
References: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
Message-ID: <poWxgvsCELhK4MLZYMuysw10Q6g-optS6-P20ulo-A8=.8414534c-2916-4abb-9ba4-b0299b9e3200@github.com>

> This is a retake on https://github.com/openjdk/jdk/pull/15096.
> 
> I tried to fix the remaining issues in that PR, but could not push them. In the end, it seemed easier to create a new branch in my own personal fork.
> 
> The majority of the work in this PR has been done by @TheShermanTanker. I have stepped in and fixed the remaining comments, reverted some additional unneeded changed code, and also tried to minimize code duplication in `awt_PrintJob.cpp`.

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

 - Merge branch 'master' into awt-permissive-minus
 - 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18584/files
  - new: https://git.openjdk.org/jdk/pull/18584/files/e9780f0c..868dc56d

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

  Stats: 9831 lines in 307 files changed: 3321 ins; 4776 del; 1734 mod
  Patch: https://git.openjdk.org/jdk/pull/18584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18584/head:pull/18584

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

From tr at openjdk.org  Fri Apr  5 04:35:25 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Apr 2024 04:35:25 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v10]
In-Reply-To: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
Message-ID: <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>

> Convert and open source these manual applet test to main based:
> java/awt/Frame/MegaIconTest/MegaIconTest.html
> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
> 
> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.

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

  Review comments updated - SizeMinimizedTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18448/files
  - new: https://git.openjdk.org/jdk/pull/18448/files/93a24977..30cd1c04

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

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

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

From tr at openjdk.org  Fri Apr  5 04:35:26 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Apr 2024 04:35:26 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v9]
In-Reply-To: <5258N78r8_XvKYWtr_q-G8iv1qVr6fuMS1wIhfWKL7o=.08f42753-4a29-4242-8bde-719dc3277365@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <p4d9dKurkPN0gA1BfZYzcTSzgB2evHWQubSGuolaXgo=.1ad3228e-c41a-497a-b0ef-4eebc7cb339d@github.com>
 <5258N78r8_XvKYWtr_q-G8iv1qVr6fuMS1wIhfWKL7o=.08f42753-4a29-4242-8bde-719dc3277365@github.com>
Message-ID: <KLYjkfOm0XfuDJ4oh0E78zYKFxeNUOn1jK1ux2A8y_M=.9350e80b-c40a-40ec-818e-496d0f8cc351@github.com>

On Thu, 4 Apr 2024 17:20:14 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments updated - SizeMinimizedTest
>
> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 37:
> 
>> 35:  * @bug 4065534
>> 36:  * @summary Frame.setSize() doesn't change size if window is in an iconified state
>> 37:  * @run main/manual SizeMinimizedTest
> 
> manual should be removed since it is automated now. 
> Does CI Testing look good with the updated test changes?

Yes, CI testing is good. Except linux which I have probemListed.

> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 43:
> 
>> 41:     private static Frame frame;
>> 42:     private static final int INITIAL_WIDTH = 100;
>> 43:     private static final int INITIAL_HEIGHT = 100;
> 
> Instead of defining width and height separately you can re-use the same constant by defining it as INITIAL_SIZE.
> Suggestion:
> 
>     private static final int INITIAL_SIZE = 100;

Done.

> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 47:
> 
>> 45:     private static final int INITIAL_Y = 50;
>> 46:     private static final int RESET_WIDTH = 200;
>> 47:     private static final int RESET_HEIGHT = 200;
> 
> Same here, can be renamed as one single constant RESET_SIZE.

Done.

> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 58:
> 
>> 56:         Robot robot = new Robot();
>> 57:         try {
>> 58:             frame = new Frame("frame size test");
> 
> Suggestion:
> 
>             frame = new Frame("Frame size test");

Done.

> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 69:
> 
>> 67:                     System.out.println("Initial Frame Location: " + frame.getLocationOnScreen());
>> 68:                 }
>> 69:             });
> 
> This windowlistener should be added before `frame.setVisible(true);` else the initial frame size and location are not logged. 
> Moving the creation of UI to a separate method (eg. createUI) makes the code cleaner.

Done.

> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 84:
> 
>> 82:                         }
>> 83: 
>> 84:                         expectedLoc = new Point(INITIAL_X + OFFSET * iterationCnt, INITIAL_Y);
> 
> Please fix line-lengths.

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552862938
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552863068
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552863489
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552863171
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552863416
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1552863268

From tr at openjdk.org  Fri Apr  5 04:41:09 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 5 Apr 2024 04:41:09 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel
In-Reply-To: <vlZ8eKbOk2wcvSOKTp97ny4sFDFtsJoMU7CmFfmHBuI=.d51febf3-fade-4436-8f22-c4826f2c76e0@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <9wvHs-0itLtMpQ9o5qQ5U6YpisjGTB82FtCWj7Iqik8=.43e11900-a030-4871-950e-95d8d9e9f2bc@github.com>
 <MM6rMGZEZ-ojvbfHHIcg_ZN5JhEgYcsX6q45lGwMpC4=.4278faa2-259b-4236-8a39-b5319df78bc5@github.com>
 <nXyBZE8rT0f9LsGliZ-BqMZ8AdHurLpNL1_SusHeuCY=.54952fd6-5bba-46e4-8b1a-819dd8fc0ec8@github.com>
 <sDXCd9U_Gcvaiaa83YTJKQJkgJwwWXDV4fbGjj1aEOo=.092199bf-39eb-43b7-89a0-f7fa3913a7b5@github.com>
 <Ip0JayogCimkItLvNzyUbDFQ6o8y6R_BUqVF3YWqgyc=.e6bcf597-fd41-4c75-ae54-872c8c4ab140@github.com>
 <IXftVfnWisE5x9951KLLKhkoPbFXysdtR_yLYM4Wuic=.42a7fed8-70e4-44d7-a7ce-6d746d1d4bfd@github.com>
 <vlZ8eKbOk2wcvSOKTp97ny4sFDFtsJoMU7CmFfmHBuI=.d51febf3-fade-4436-8f22-c4826f2c76e0@github.com>
Message-ID: <V9QV5Vc-VFprvH0Wyr3ulas6e8uE4IiJBA9rxWAZalk=.b9b5e359-deb1-4953-a222-5a1e4c2d5e21@github.com>

On Thu, 4 Apr 2024 17:18:48 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > > > > Can you please explain why you need to handle MultiResolutionImage for this printing issue for NimbusL&F and why was it not needed for other L&F Also, you need to add this bugid to the test
> > > > > > 
> > > > > > 
> > > > > > The fix is for L&F other than Nimbus. It is working in Nimbus since Image drawing is handled by SunGraphics2D class in [drawHIDPIImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/java2d/SunGraphics2D.java#L3126) method. Whereas other L&F, pathGraphics handles ImageDrawing where MultiResolutionImage is not yet handled. The fix which I proposed for [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) bug fixed for Non-Nimbus L&F but caused regression for Nimbus. Hence after further analysis and study the root cause was found out to be Non-handling of MultiResolutionImage in [getBufferedImage()](https://github.com/openjdk/jdk/blob/b9da14012da5f1f72d4f6e690c18a43e87523173/src/java.desktop/share/classes/sun/print/PathGraphics.java#L1122).
> > > > > 
> > > > > 
> > > > > I guess the PathGraphics path should be used for printing images and should be common for all so why Nimbus is going via SunGraphics2D? [and it seems you updated the summary to include Aqua so Aqua is also going via SunGraphics2D?]
> > > > 
> > > > 
> > > > Yes, the issue is found in Aqua also and that too uses SunGraphics2D. And regarding why SunGraphics2D is used for Nimbus and Aqua, its because in Nimbus PeekGraphics is used which in-turn useses SunGraphics2D and in other its PW/WPathGraphics. I'm not sure why this is different.
> > > 
> > > 
> > > Can you point to the code where it uses PeekGraphics in Nimbus/Aqua and the subsequent code from where is starts to bifurcate in other L&F meaning where it starts to uses PeekGraphics for Nimbus/Aqua and PathGraphics for others?
> > 
> > 
> > Yeah, it is from RasterPrinterJob class [here](https://github.com/openjdk/jdk/blob/21867c929a2f2c961148f2cd1e79d672ac278d27/src/java.desktop/share/classes/sun/print/RasterPrinterJob.java#L2298). And that is because of nonSolidColors present in Nimbus and Aqua L&F.
> 
> I didn't get how it creates PeekGraphics for Nimbus/Aqua and PathGraphics for others? I guess RasterPrinterJob will delegate to WPrinterJob in windows and PSPrinterJob in unix and it is not dependant on L&F...

It is because of this condition check `metrics.hasNonSolidColors()` which is true for Nimbus & Aqua. [Here](https://github.com/openjdk/jdk/blob/0b01144ecec1283adaaaf1a7f53d075a56f030ae/src/java.desktop/share/classes/sun/print/PSPrinterJob.java#L1076).

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

PR Comment: https://git.openjdk.org/jdk/pull/18187#issuecomment-2038909946

From abhiscxk at openjdk.org  Fri Apr  5 05:26:09 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 5 Apr 2024 05:26:09 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <_-xzgTiORLrtIpAWxaSTmDGhwB8XA1Z5y8gS9uFPfQo=.e3ddeefe-c724-4123-ba8b-73c73f60891b@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
 <5s7eNsEBN6MAuwzCFTVJ5hfvbblPhmwtTDNvTiG_8wI=.7f3e38e9-751e-40b3-98b9-6f73fd4cbc61@github.com>
 <cJ9hwWEBm2o-NI3fqI4YnaZI02FApQjKKzHPLkEoD1E=.8c9af358-0984-4b17-84fe-47779cfa5b3c@github.com>
 <_-xzgTiORLrtIpAWxaSTmDGhwB8XA1Z5y8gS9uFPfQo=.e3ddeefe-c724-4123-ba8b-73c73f60891b@github.com>
Message-ID: <_czJuU7Z08QCrp2d8auiRguEKUOdLR208gWCu4Jueb8=.5499751b-e403-4bc2-92a3-03bbf3aa4a25@github.com>

On Thu, 4 Apr 2024 17:11:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> you have already added...i am asking it it's needed?

ohh yes, i messed up with other file.

> SInce you are introducing those 3 property in NimbusLookANdFeel, is this defines needed in skin.laf?

In NimbusLookAndFeel there is no such property defined. To keep JTabbedPane behavior consistent in Nimbus LAF, properties are added to skin.laf. Else the ContentArea color will be same as `JPanel color when non-opaque and JTabbedPane background color when opaque.`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1552942719

From abhiscxk at openjdk.org  Fri Apr  5 05:32:10 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 5 Apr 2024 05:32:10 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <AiDLz1rlEahkR-9yVHchm5VOU4MwqLHv0XMU4vwEJbo=.8ad84fc2-4a97-4b88-844d-a29f6322117e@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
 <AiDLz1rlEahkR-9yVHchm5VOU4MwqLHv0XMU4vwEJbo=.8ad84fc2-4a97-4b88-844d-a29f6322117e@github.com>
Message-ID: <WmBHLEE7MnEVxlmmI1XK4cc_41sq89DMLnK2-DBDN6E=.216fcfae-eb36-4387-8765-9c62a53c1a55@github.com>

On Thu, 4 Apr 2024 17:10:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 1026:
> 
>> 1024:             "TabbedPane.selected", tabbedPaneBg,
>> 1025:             "TabbedPane.contentOpaque", Boolean.TRUE,
>> 1026:             "TabbedPane.contentAreaColor", tabbedPaneBg,
> 
> `TabbedPane.contentOpaque` and `TabbedPane.tabsOpaque` seems to go hand-in-hand and there's another issue for it https://bugs.openjdk.org/browse/JDK-6462396 so if we are supporting one and not other, it may not have desired effect..

Do you mean we should handle `TabbedPane.tabsOpaque` property as well along with `TabbedPane.contentOpaque` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1552946309

From jwaters at openjdk.org  Fri Apr  5 05:51:09 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 5 Apr 2024 05:51:09 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v2]
In-Reply-To: <poWxgvsCELhK4MLZYMuysw10Q6g-optS6-P20ulo-A8=.8414534c-2916-4abb-9ba4-b0299b9e3200@github.com>
References: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
 <poWxgvsCELhK4MLZYMuysw10Q6g-optS6-P20ulo-A8=.8414534c-2916-4abb-9ba4-b0299b9e3200@github.com>
Message-ID: <HtwjJxzh6bhQeO-U9y8m4KIReHhu-p_Ds-coz_rvIZE=.6f1e2f42-ceab-48b8-958e-138eace717f5@github.com>

On Thu, 4 Apr 2024 22:47:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is a retake on https://github.com/openjdk/jdk/pull/15096.
>> 
>> I tried to fix the remaining issues in that PR, but could not push them. In the end, it seemed easier to create a new branch in my own personal fork.
>> 
>> The majority of the work in this PR has been done by @TheShermanTanker. I have stepped in and fixed the remaining comments, reverted some additional unneeded changed code, and also tried to minimize code duplication in `awt_PrintJob.cpp`.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into awt-permissive-minus
>  - 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler

src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6370:

> 6368:         AwtComponent *awtParent = NULL;
> 6369: 
> 6370:         if (self == NULL) {

I had missed this in my earlier sweep of the changes, but didn't Phil request that both the check for self and parent be merged into self == NULL || parent == NULL? (Or as I'd prefer, nullptr)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18584#discussion_r1552961774

From abhiscxk at openjdk.org  Fri Apr  5 06:58:19 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 5 Apr 2024 06:58:19 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+
Message-ID: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>

Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.

`@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`

CI testing is green for the modified test. Link attached in JBS.

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

Commit messages:
 - ComboBox color issue fix

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

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

From ihse at openjdk.org  Fri Apr  5 08:58:16 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Apr 2024 08:58:16 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v2]
In-Reply-To: <HtwjJxzh6bhQeO-U9y8m4KIReHhu-p_Ds-coz_rvIZE=.6f1e2f42-ceab-48b8-958e-138eace717f5@github.com>
References: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
 <poWxgvsCELhK4MLZYMuysw10Q6g-optS6-P20ulo-A8=.8414534c-2916-4abb-9ba4-b0299b9e3200@github.com>
 <HtwjJxzh6bhQeO-U9y8m4KIReHhu-p_Ds-coz_rvIZE=.6f1e2f42-ceab-48b8-958e-138eace717f5@github.com>
Message-ID: <a6GzPOYMQBmGESX9uxP93hUPqKzKxfdyPXkDxmR84j0=.5b21b082-fb27-41bd-826b-b77eb3201471@github.com>

On Fri, 5 Apr 2024 05:48:40 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into awt-permissive-minus
>>  - 8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler
>
> src/java.desktop/windows/native/libawt/windows/awt_Component.cpp line 6370:
> 
>> 6368:         AwtComponent *awtParent = NULL;
>> 6369: 
>> 6370:         if (self == NULL) {
> 
> I had missed this in my earlier sweep of the changes, but didn't Phil request that both the check for self and parent be merged into self == NULL || parent == NULL? (Or as I'd prefer, nullptr)

I noticed Phil's comment, but I could not make it look nice. For instance, the NPE error message was unclear, and you could not see the connection between self->awtComponent and parent->awtParent, which was obvious in the original code.

In the end, I thought it was preferable to use the exact same style when expanding the macro as elsewhere. That creates a common pattern across the codebase.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18584#discussion_r1553174771

From ihse at openjdk.org  Fri Apr  5 08:58:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 5 Apr 2024 08:58:18 GMT
Subject: Integrated: 8307160: Fix AWT/2D/A11Y to support the permissive- flag
 on the Microsoft Visual C compiler
In-Reply-To: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
References: <lAFmkUV226ajDupH5vvhyyK7UIWh2J5Spl27kCyDmB4=.00529e3e-8548-4120-b54a-4c20d6d774d3@github.com>
Message-ID: <bZoVGAJB6ykDxOsrsf2_uyPzHcinmFPaIT-8Za5Tc0I=.815b4c4a-779d-47f2-abfb-144787884eda@github.com>

On Tue, 2 Apr 2024 15:45:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is a retake on https://github.com/openjdk/jdk/pull/15096.
> 
> I tried to fix the remaining issues in that PR, but could not push them. In the end, it seemed easier to create a new branch in my own personal fork.
> 
> The majority of the work in this PR has been done by @TheShermanTanker. I have stepped in and fixed the remaining comments, reverted some additional unneeded changed code, and also tried to minimize code duplication in `awt_PrintJob.cpp`.

This pull request has now been integrated.

Changeset: 8bc1867d
Author:    Julian Waters <jwaters at openjdk.org>
Committer: Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8bc1867da78ea0b7664892ee277af413ef503b61
Stats:     428 lines in 12 files changed: 284 ins; 50 del; 94 mod

8307160: Fix AWT/2D/A11Y to support the permissive- flag on the Microsoft Visual C compiler

Co-authored-by: Magnus Ihse Bursie <ihse at openjdk.org>
Reviewed-by: jwaters, prr

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

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

From aivanov at openjdk.org  Fri Apr  5 15:51:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 5 Apr 2024 15:51:10 GMT
Subject: RFR: 8329761: Remove unused KeyBuilder and unusedSets from
 StyleContext
Message-ID: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>

Remove unused class `KeyBuilder` and unused field `unusedSets`.  
Update a comment which used javadoc syntax.  
Mark `KeyEnumeration` and `FontKey` classes as *`final`*.

All the client tests are green.

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

Commit messages:
 - 8329761: Remove unused KeyBuilder and unusedSets from StyleContext

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

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

From serb at openjdk.org  Fri Apr  5 16:33:09 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 5 Apr 2024 16:33:09 GMT
Subject: RFR: 8329761: Remove unused KeyBuilder and unusedSets from
 StyleContext
In-Reply-To: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
References: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
Message-ID: <nCZrVPmr-d4o9jXrpXa6gxBDvBsTyzZvvtq4y3kJNdY=.42b19901-66f2-4c89-8da3-c04b6bbdf434@github.com>

On Fri, 5 Apr 2024 15:46:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove unused class `KeyBuilder` and unused field `unusedSets`.  
> Update a comment which used javadoc syntax.  
> Mark `KeyEnumeration` and `FontKey` classes as *`final`*.
> 
> All the client tests are green.

Could you please check the history of that file, is these unused due to some functionality was deleted and this was missed, or we planned to implement something and forgot?

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

PR Comment: https://git.openjdk.org/jdk/pull/18659#issuecomment-2040218603

From honkar at openjdk.org  Fri Apr  5 17:27:13 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Apr 2024 17:27:13 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v10]
In-Reply-To: <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
Message-ID: <8IFIW_8D0GwhDfS_2HV1G1e7tr90-dSMqgZSKJUD2-M=.dba954f4-8a39-442e-bb8a-d6d3d2cbd138@github.com>

On Fri, 5 Apr 2024 04:35:25 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Convert and open source these manual applet test to main based:
>> java/awt/Frame/MegaIconTest/MegaIconTest.html
>> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
>> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
>> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
>> 
>> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments updated - SizeMinimizedTest

Updated changes look good.

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 60:

> 58:             });
> 59:             robot.waitForIdle();
> 60:             robot.delay(100);

The delay can be increased here since it is after createUI.

Suggestion:

            robot.delay(1000);

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18448#pullrequestreview-1983759081
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1554031631

From honkar at openjdk.org  Fri Apr  5 17:30:03 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Apr 2024 17:30:03 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v10]
In-Reply-To: <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
Message-ID: <dznICoJ1TIdvNDKf13NezpPh2WEZo6bGRaTFTgVCNPY=.099b12fe-00cc-4c4f-ba25-1948ed62376f@github.com>

On Fri, 5 Apr 2024 04:35:25 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Convert and open source these manual applet test to main based:
>> java/awt/Frame/MegaIconTest/MegaIconTest.html
>> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
>> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
>> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
>> 
>> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments updated - SizeMinimizedTest

test/jdk/java/awt/Frame/SizeMinimizedTest.java line 70:

> 68:             });
> 69:             robot.waitForIdle();
> 70:             robot.delay(100);

Minor: Adding a newline after each `robot.delay(100)`  makes the code easier to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1554035086

From honkar at openjdk.org  Fri Apr  5 17:49:12 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 5 Apr 2024 17:49:12 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v10]
In-Reply-To: <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
Message-ID: <75kE9UgpHNwrhN7zCeckM3RXezUD-Ews3VK0cJtwxxI=.78a056a8-b9c4-4181-a440-f8f3c9ff0226@github.com>

On Fri, 5 Apr 2024 04:35:25 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Convert and open source these manual applet test to main based:
>> java/awt/Frame/MegaIconTest/MegaIconTest.html
>> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
>> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
>> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
>> 
>> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments updated - SizeMinimizedTest

Changes requested by honkar (Reviewer).

test/jdk/ProblemList.txt line 803:

> 801: java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java 8258103 linux-all
> 802: java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java 8016266 linux-x64
> 803: java/awt/Frame/SizeMinimizedTest.java 4065534 linux-x64

The problemlist should always reference a JBS issue that is in open status, which is [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) in this case and not [JDK-4065534](https://bugs.openjdk.org/browse/JDK-4065534).

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

PR Review: https://git.openjdk.org/jdk/pull/18448#pullrequestreview-1983796908
PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1554053358

From aivanov at openjdk.org  Fri Apr  5 18:12:09 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 5 Apr 2024 18:12:09 GMT
Subject: RFR: 8329761: Remove unused KeyBuilder and unusedSets from
 StyleContext
In-Reply-To: <nCZrVPmr-d4o9jXrpXa6gxBDvBsTyzZvvtq4y3kJNdY=.42b19901-66f2-4c89-8da3-c04b6bbdf434@github.com>
References: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
 <nCZrVPmr-d4o9jXrpXa6gxBDvBsTyzZvvtq4y3kJNdY=.42b19901-66f2-4c89-8da3-c04b6bbdf434@github.com>
Message-ID: <kzsfvVt1Ofie8I4ozevt8fMoMqtZ1XdZZe4ZdBOON6U=.cbc5b425-8421-47d6-83e8-32638ca3f05e@github.com>

On Fri, 5 Apr 2024 16:29:56 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Could you please check the history of that file, is these unused due to some functionality was deleted and this was missed, or we planned to implement something and forgot?

Both were used in pre-historic days.

The `unusedSets` field tracked the number of unused attribute sets passed to the `reclaim` method. It's been unused since `attributePool` became `WeakHashMap`.

The `KeyBuilder` was used for searching? The `search` field was an instance of `KeyBuilder`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18659#issuecomment-2040362838

From dnguyen at openjdk.org  Fri Apr  5 18:29:12 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 5 Apr 2024 18:29:12 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+
In-Reply-To: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
Message-ID: <TYcwMAybG_NsPsWNRgiQYYyPFLRJMWWopsST6MKYwus=.3ce3a538-643a-4e99-b518-2b72918a0bf2@github.com>

On Fri, 5 Apr 2024 06:54:46 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
> 
> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
> 
> CI testing is green for the modified test. Link attached in JBS.

Changes requested by dnguyen (Committer).

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 132:

> 130:                 eColor2 = new Color(enabledImage2.getRGB(x + 10, y + 2));
> 131:                 dColor1 = new Color(disabledImage.getRGB(x, y));
> 132:                 dColor2 = new Color(disabledImage2.getRGB(x + 10, y + 2));

I noticed with these components, sometimes the size varies slightly between different desktop scaling values or resolutions. You have exact combobox pixel sizes in the comments, but does this stay the same when you set your device to 200% or other values?

Maybe best to leave out the exact combo size from the comments regardless.

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 144:

> 142:             }
> 143:         }
> 144:         System.out.println("Test Passed: "+lafName);

Suggestion:

        System.out.println("Test Passed: " + lafName);

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 150:

> 148:         int redDiff = c1.getRed() - c2.getRed();
> 149:         int blueDiff = c1.getBlue() - c2.getBlue();
> 150:         int greenDiff = c1.getGreen() - c2.getGreen();

Does this need Math.abs to get the absolute value of the difference?

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

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-1983854777
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1554097166
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1554089283
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1554092528

From serb at openjdk.org  Fri Apr  5 19:42:10 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 5 Apr 2024 19:42:10 GMT
Subject: RFR: 8329761: Remove unused KeyBuilder and unusedSets from
 StyleContext
In-Reply-To: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
References: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
Message-ID: <y2JjUV8tiXBz8EJ8H_PL86QXpcG3hNLffujqk7cMqkc=.9f6f3911-eb7b-4ee0-8a0e-0ea7efe91dc1@github.com>

On Fri, 5 Apr 2024 15:46:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove unused class `KeyBuilder` and unused field `unusedSets`.  
> Update a comment which used javadoc syntax.  
> Mark `KeyEnumeration` and `FontKey` classes as *`final`*.
> 
> All the client tests are green.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18659#pullrequestreview-1984044967

From abhiscxk at openjdk.org  Fri Apr  5 19:47:23 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 5 Apr 2024 19:47:23 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
Message-ID: <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>

> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
> 
> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
> 
> CI testing is green for the modified test. Link attached in JBS.

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

  Review comment update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18644/files
  - new: https://git.openjdk.org/jdk/pull/18644/files/12a1bf40..170d45c1

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

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

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

From abhiscxk at openjdk.org  Fri Apr  5 19:47:23 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 5 Apr 2024 19:47:23 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <TYcwMAybG_NsPsWNRgiQYYyPFLRJMWWopsST6MKYwus=.3ce3a538-643a-4e99-b518-2b72918a0bf2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <TYcwMAybG_NsPsWNRgiQYYyPFLRJMWWopsST6MKYwus=.3ce3a538-643a-4e99-b518-2b72918a0bf2@github.com>
Message-ID: <nX619t_RG1UIM_jwBu3FLmEymH0QDjSeCO8KWIx5oAk=.3d9b2269-f462-4e34-bb8b-eb099193222a@github.com>

On Fri, 5 Apr 2024 18:22:18 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 update
>
> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 144:
> 
>> 142:             }
>> 143:         }
>> 144:         System.out.println("Test Passed: "+lafName);
> 
> Suggestion:
> 
>         System.out.println("Test Passed: " + lafName);

Updated.

> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 150:
> 
>> 148:         int redDiff = c1.getRed() - c2.getRed();
>> 149:         int blueDiff = c1.getBlue() - c2.getBlue();
>> 150:         int greenDiff = c1.getGreen() - c2.getGreen();
> 
> Does this need Math.abs to get the absolute value of the difference?

That makes sense. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1554206941
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1554209216

From abhiscxk at openjdk.org  Fri Apr  5 19:49:59 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 5 Apr 2024 19:49:59 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <TYcwMAybG_NsPsWNRgiQYYyPFLRJMWWopsST6MKYwus=.3ce3a538-643a-4e99-b518-2b72918a0bf2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <TYcwMAybG_NsPsWNRgiQYYyPFLRJMWWopsST6MKYwus=.3ce3a538-643a-4e99-b518-2b72918a0bf2@github.com>
Message-ID: <Q3OxmpmnzJmWEWqdKO9Td_OQtbbewUFkpn0PmFctOJw=.e53416f6-3aeb-458c-87dc-71db1f498ae2@github.com>

On Fri, 5 Apr 2024 18:25:45 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> I noticed with these components, sometimes the size varies slightly between different desktop scaling values or resolutions. You have exact combobox pixel sizes in the comments, but does this stay the same when you set your device to 200% or other values?
Maybe best to leave out the exact combo size from the comments regardless.

Checked with UIScale of 2 and the images are of same size. But your point seems valid that may vary from between different machine for different resolution or scale.
Removed the exact size from the comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1554212599

From dnguyen at openjdk.org  Fri Apr  5 22:01:18 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 5 Apr 2024 22:01:18 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>
Message-ID: <zgGsNuT0Cr69Q6u-A5xU-3GM2pbWdhd51-aoquY84vM=.9429132e-9bc3-4b6c-a02c-2cd8ddff3342@github.com>

On Fri, 5 Apr 2024 19:47:23 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

Changes look good to me now.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-1984257082

From djelinski at openjdk.org  Mon Apr  8 04:33:11 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 8 Apr 2024 04:33:11 GMT
Subject: Integrated: 8329340: Remove unused libawt code
In-Reply-To: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
References: <soXzrbPM_yKPwrrJkpIe4pQlWKMfdJ0MM87MV7WmTDE=.10c905d1-15de-4b85-91c3-bce72065000f@github.com>
Message-ID: <Codkebww0-8unfdLvGtxGgPHhNoPEPfkAlf-DH1EFRc=.9c84d298-fe74-40bf-8712-b5e637802682@github.com>

On Fri, 29 Mar 2024 18:23:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Please review this PR that removes unused functions, variables, and WM_AWT window messages.
> 
> The unused code was detected by automated analysis (MSVC compiler and linker, CodeQL analyzer). I manually verified every symbol before removing. Mach5 client libs testing clean.
> 
> Some WM_AWT messages have different IDs after this change. The IDs have changed a few times before, so I think this shouldn't be a problem.

This pull request has now been integrated.

Changeset: 51b0abc8
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/51b0abc87439014c4c5022c0057614f99a741ddd
Stats:     735 lines in 23 files changed: 0 ins; 712 del; 23 mod

8329340: Remove unused libawt code
8315693: Remove WM_AWT_SET_SCROLL_INFO message

Reviewed-by: prr, aivanov

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

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

From tr at openjdk.org  Mon Apr  8 04:37:13 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Apr 2024 04:37:13 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v10]
In-Reply-To: <75kE9UgpHNwrhN7zCeckM3RXezUD-Ews3VK0cJtwxxI=.78a056a8-b9c4-4181-a440-f8f3c9ff0226@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
 <75kE9UgpHNwrhN7zCeckM3RXezUD-Ews3VK0cJtwxxI=.78a056a8-b9c4-4181-a440-f8f3c9ff0226@github.com>
Message-ID: <o2OfL9BJniIfCb0V_GuqK1Qm-Km7a8FUbYUeywIySQk=.390783f1-a581-407a-8dc3-0821b8c58c4f@github.com>

On Fri, 5 Apr 2024 17:46:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments updated - SizeMinimizedTest
>
> test/jdk/ProblemList.txt line 803:
> 
>> 801: java/awt/FullScreen/TranslucentWindow/TranslucentWindow.java 8258103 linux-all
>> 802: java/awt/Focus/FrameMinimizeTest/FrameMinimizeTest.java 8016266 linux-x64
>> 803: java/awt/Frame/SizeMinimizedTest.java 4065534 linux-x64
> 
> The problemlist should always reference a JBS issue that is in open status, which is [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) in this case and not [JDK-4065534](https://bugs.openjdk.org/browse/JDK-4065534).

But we are not updating the with [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915) right? It should be the test bug ID I guess, else how will it be problem listed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1555209957

From tr at openjdk.org  Mon Apr  8 04:50:44 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Apr 2024 04:50:44 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v11]
In-Reply-To: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
Message-ID: <WhMJgqxxWhxjHHi2k2vIg8Lo-0i-s2DHuuKwn7dAxY4=.e5e0b304-4d76-42c7-9f71-54f25bea5e48@github.com>

> Convert and open source these manual applet test to main based:
> java/awt/Frame/MegaIconTest/MegaIconTest.html
> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
> 
> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.

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

 - Review comments updated - SizeMinimizedTest
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8328482
 - Review comments updated - SizeMinimizedTest
 - Review comments updated - SizeMinimizedTest
 - Added opaque image
 - Reveiw updates
 - Reveiw updates
 - Reveiw updates and SizeMinimizedTest converted to auto test
 - fight.gif added
 - Images updated
 - ... and 4 more: https://git.openjdk.org/jdk/compare/67682972...373c16cd

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18448/files
  - new: https://git.openjdk.org/jdk/pull/18448/files/30cd1c04..373c16cd

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

  Stats: 78677 lines in 2828 files changed: 17722 ins; 15691 del; 45264 mod
  Patch: https://git.openjdk.org/jdk/pull/18448.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18448/head:pull/18448

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

From tr at openjdk.org  Mon Apr  8 04:50:44 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Apr 2024 04:50:44 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v10]
In-Reply-To: <8IFIW_8D0GwhDfS_2HV1G1e7tr90-dSMqgZSKJUD2-M=.dba954f4-8a39-442e-bb8a-d6d3d2cbd138@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <8FJ-Suoaui-nfXHZygVs5hJFsxh_1YvvLg7awBqEBx8=.c8153a54-a6a9-4b6c-9963-59a1a9ee77cb@github.com>
 <8IFIW_8D0GwhDfS_2HV1G1e7tr90-dSMqgZSKJUD2-M=.dba954f4-8a39-442e-bb8a-d6d3d2cbd138@github.com>
Message-ID: <Zrd5J5EyXdHOXoHfOsbP3bEQo_-EidXYPFos7CH24Bs=.f13325ea-41d0-462b-a6ec-241282e7c955@github.com>

On Fri, 5 Apr 2024 17:24:06 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments updated - SizeMinimizedTest
>
> test/jdk/java/awt/Frame/SizeMinimizedTest.java line 60:
> 
>> 58:             });
>> 59:             robot.waitForIdle();
>> 60:             robot.delay(100);
> 
> The delay can be increased here since it is after createUI.
> 
> Suggestion:
> 
>             robot.delay(1000);

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18448#discussion_r1555215888

From tr at openjdk.org  Mon Apr  8 05:40:10 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Apr 2024 05:40:10 GMT
Subject: RFR: 8329761: Remove unused KeyBuilder and unusedSets from
 StyleContext
In-Reply-To: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
References: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
Message-ID: <HDyQU8zxERJXsVRViic9c00E0LQhpcHwlaNWIYzaOZA=.5b8926da-148d-41f1-8ce9-dac7e62d6d78@github.com>

On Fri, 5 Apr 2024 15:46:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove unused class `KeyBuilder` and unused field `unusedSets`.  
> Update a comment which used javadoc syntax.  
> Mark `KeyEnumeration` and `FontKey` classes as *`final`*.
> 
> All the client tests are green.

Marked as reviewed by tr (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18659#pullrequestreview-1985477472

From tr at openjdk.org  Mon Apr  8 05:51:00 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 8 Apr 2024 05:51:00 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame
In-Reply-To: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
Message-ID: <IRSrpYBuZspOqATTfCh_S2rBKOLQ9_iz_N5pWJ2ONck=.974698e8-ead2-462e-949a-9ac110e90473@github.com>

On Thu, 4 Apr 2024 12:07:46 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
> 
> Renjith.

Did you test it for other L&F also?

test/jdk/java/awt/print/PageFormat/Orient.java line 57:

> 55:             "Test failed if the oval on the page clipped against the imageable area.";
> 56: 
> 57:     private static void init() throws PrinterException {

`init()` can be renamed since the test is no longer applet based.

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

PR Review: https://git.openjdk.org/jdk/pull/18624#pullrequestreview-1985485967
PR Review Comment: https://git.openjdk.org/jdk/pull/18624#discussion_r1555251504

From abhiscxk at openjdk.org  Mon Apr  8 05:58:13 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 8 Apr 2024 05:58:13 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame
In-Reply-To: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
Message-ID: <q-j8Msof_uJFWiFPT6H8qgaph4N94SinUAgL7q0LKQM=.b828dd85-1459-4afd-80cd-854a02e6bb04@github.com>

On Thu, 4 Apr 2024 12:07:46 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
> 
> Renjith.

test/jdk/java/awt/print/PageFormat/Orient.java line 38:

> 36:  * @bug 4236095
> 37:  * @summary  Confirm that you get three pages of output, one
> 38:  *           each in portrait, landscape, and reverse landscape

Suggestion:

 *           each in portrait, landscape and reverse landscape

test/jdk/java/awt/print/PageFormat/Orient.java line 47:

> 45: public class Orient implements Printable {
> 46:     private static final String INSTRUCTIONS =
> 47:             "This test will automatically initiate a print.\n\n" +

Can use Text Block style for better readability.

String INSTRUCTIONS = """
...""".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18624#discussion_r1555254968
PR Review Comment: https://git.openjdk.org/jdk/pull/18624#discussion_r1555254794

From rkannathpari at openjdk.org  Mon Apr  8 06:14:18 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 8 Apr 2024 06:14:18 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled
Message-ID: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>

Hi Reviewers,

Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.

Regards,
Renjith.

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

Commit messages:
 - Removed space
 - JDK-8328977 : JEditorPane.setPage not thread-safe, pageLoader not cancelled

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

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

From rkannathpari at openjdk.org  Mon Apr  8 07:57:11 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Mon, 8 Apr 2024 07:57:11 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
Message-ID: <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>

> Hi Reviewers,
> 
> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
> 
> Renjith.

Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:

 - Updated insturction style
 - Updated suggesions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18624/files
  - new: https://git.openjdk.org/jdk/pull/18624/files/e151b4ca..fcf3830a

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

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

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

From psadhukhan at openjdk.org  Mon Apr  8 09:45:10 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 8 Apr 2024 09:45:10 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in NimbusLookAndFeel [v2]
In-Reply-To: <WdIr-XJAfVq7KOMVFjJfj7ObW-itoexFlcd75x302EE=.c1f35956-1e62-4c51-8d14-c13a2cf7c758@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <WdIr-XJAfVq7KOMVFjJfj7ObW-itoexFlcd75x302EE=.c1f35956-1e62-4c51-8d14-c13a2cf7c758@github.com>
Message-ID: <6H0X5J1HCpgp5QaaTmI-eRFulcSzH38Rm1ETsJd4F0k=.82dd9a37-8c35-42f9-8d4b-e6aad6392d6c@github.com>

On Thu, 4 Apr 2024 10:35:22 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.
>
> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Spacing updates
>  - Updated test with BugID and copyright year

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 2:

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

should be 2024

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1555532274

From dmarkov at openjdk.org  Mon Apr  8 13:20:09 2024
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Mon, 8 Apr 2024 13:20:09 GMT
Subject: RFR: 8329510: Update ProblemList for
 JFileChooser/8194044/FileSystemRootTest.java
In-Reply-To: <QDbaHbypmsltrQkLn_jhQsVvu3syniL6tkPYczy7rVs=.9f78e299-ad12-40f4-a89f-976ad5e6e1be@github.com>
References: <QDbaHbypmsltrQkLn_jhQsVvu3syniL6tkPYczy7rVs=.9f78e299-ad12-40f4-a89f-976ad5e6e1be@github.com>
Message-ID: <1H4_geFUXe9Tt2e1fTj_yNftl9jkEYzRBJVCS-mk2Fc=.b78374d1-8be6-4d23-86c7-2e4b02bdb7c5@github.com>

On Tue, 2 Apr 2024 10:29:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the problem-list entry for ` javax/swing/JFileChooser/8194044/FileSystemRootTest.java` to refer to [JDK-8327236](https://bugs.openjdk.org/browse/JDK-8327236) under which the failure with `"root drive reported as false"` is tracked.

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18580#pullrequestreview-1986428556

From aivanov at openjdk.org  Mon Apr  8 15:31:05 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 8 Apr 2024 15:31:05 GMT
Subject: Integrated: 8329510: Update ProblemList for
 JFileChooser/8194044/FileSystemRootTest.java
In-Reply-To: <QDbaHbypmsltrQkLn_jhQsVvu3syniL6tkPYczy7rVs=.9f78e299-ad12-40f4-a89f-976ad5e6e1be@github.com>
References: <QDbaHbypmsltrQkLn_jhQsVvu3syniL6tkPYczy7rVs=.9f78e299-ad12-40f4-a89f-976ad5e6e1be@github.com>
Message-ID: <yf-PXfBLWzPnAmbCJm3b4WB2mLbqV5dt2EkGwvCjsIQ=.d1898394-c504-4d93-b73b-20937ea185ca@github.com>

On Tue, 2 Apr 2024 10:29:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update the problem-list entry for ` javax/swing/JFileChooser/8194044/FileSystemRootTest.java` to refer to [JDK-8327236](https://bugs.openjdk.org/browse/JDK-8327236) under which the failure with `"root drive reported as false"` is tracked.

This pull request has now been integrated.

Changeset: 74758248
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/747582484ce89e16661ef917a89adb52f5adc2e6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8329510: Update ProblemList for JFileChooser/8194044/FileSystemRootTest.java

Reviewed-by: abhiscxk, dmarkov

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

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

From aivanov at openjdk.org  Mon Apr  8 15:59:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 8 Apr 2024 15:59:10 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
Message-ID: <-yWycDwD8GQZ7cpVMnqIt9-moSMj3zp99JLjKTLLWRk=.dfabcd5d-ecbc-427e-a337-87599ae99b12@github.com>

On Fri, 29 Mar 2024 15:32:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
> 
> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
> 
> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
> 
> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
> 
> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
> 
> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
> 
> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
> 
> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.

Any volunteers to review?

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

PR Comment: https://git.openjdk.org/jdk/pull/18550#issuecomment-2043118681

From honkar at openjdk.org  Mon Apr  8 16:36:14 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 8 Apr 2024 16:36:14 GMT
Subject: RFR: 8328482: Convert and Open source few manual applet test to
 main based [v11]
In-Reply-To: <WhMJgqxxWhxjHHi2k2vIg8Lo-0i-s2DHuuKwn7dAxY4=.e5e0b304-4d76-42c7-9f71-54f25bea5e48@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
 <WhMJgqxxWhxjHHi2k2vIg8Lo-0i-s2DHuuKwn7dAxY4=.e5e0b304-4d76-42c7-9f71-54f25bea5e48@github.com>
Message-ID: <VNiAV_4hHBAKxfl_8y5tIi4qG3i_IzMT6Nl-sYbKgaA=.2e74a8b0-cf82-4778-9732-c201f5d7c2e3@github.com>

On Mon, 8 Apr 2024 04:50:44 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Convert and open source these manual applet test to main based:
>> java/awt/Frame/MegaIconTest/MegaIconTest.html
>> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
>> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
>> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
>> 
>> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.
>
> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:
> 
>  - Review comments updated - SizeMinimizedTest
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8328482
>  - Review comments updated - SizeMinimizedTest
>  - Review comments updated - SizeMinimizedTest
>  - Added opaque image
>  - Reveiw updates
>  - Reveiw updates
>  - Reveiw updates and SizeMinimizedTest converted to auto test
>  - fight.gif added
>  - Images updated
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/58b9710c...373c16cd

LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18448#pullrequestreview-1986920058

From aivanov at openjdk.org  Mon Apr  8 17:09:13 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 8 Apr 2024 17:09:13 GMT
Subject: RFR: 8305072: Win32ShellFolder2.compareTo is inconsistent [v2]
In-Reply-To: <21db5CiFTVN7scwsIHknMxF4YaVQd06m7gUOhcCLvMI=.e2f61ea7-bf9a-4632-bf45-c89f979ae806@github.com>
References: <bEiHvkFnBZDqmiqQdk_-_mATVhDbAD7NZX7VnkHLG2E=.27ee84ba-00fd-405a-9489-8fe11c215af9@github.com>
 <21db5CiFTVN7scwsIHknMxF4YaVQd06m7gUOhcCLvMI=.e2f61ea7-bf9a-4632-bf45-c89f979ae806@github.com>
Message-ID: <836hfIUb6RsqYWH99nxgvWY7F93baR--ekZHOZsS2hM=.2cf70afe-f4c0-4e34-94f6-8d3fbfb721b2@github.com>

On Tue, 5 Mar 2024 17:40:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The implementation of `Win32ShellFolder2.compareTo` is inconsistent: there are cases where  
>> `a < b & b < c but a == c`  
>> which *violates its general contract*.
>> 
>> In particular, it happens for the personal folder (*Documents*) if it is listed *twice*: as a special and as a regular folder.
>> 
>> The evaluation performed by the submitter of the bug provided enough details to create a test, reproduce the problem and finally resolve it.
>> 
>> Without the fix, the regression test always fails:
>> 
>> a < b & b < c but a >= c
>> where
>>   a = C:\Users<user>\Documents(true)
>>   b = C:\Users<user>(false)
>>   c = C:\Users<user>\Documents(false)
>> 
>> as well as for the reverse case: `a > b & b > c`.
>> 
>> How it is possible to have the same folder in a list of files twice remains unknown. I believe it is another bug in JDK, however, no one has been able to reproduce it so far.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handle fakePersonal on Windows 10
>   
>   The desktop folder on Windows 10 does not include
>   the Personal (Documents) folder.

Any other reviewer?

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

PR Comment: https://git.openjdk.org/jdk/pull/18126#issuecomment-2043254746

From serb at openjdk.org  Mon Apr  8 17:33:10 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 8 Apr 2024 17:33:10 GMT
Subject: RFR: 8305072: Win32ShellFolder2.compareTo is inconsistent [v2]
In-Reply-To: <21db5CiFTVN7scwsIHknMxF4YaVQd06m7gUOhcCLvMI=.e2f61ea7-bf9a-4632-bf45-c89f979ae806@github.com>
References: <bEiHvkFnBZDqmiqQdk_-_mATVhDbAD7NZX7VnkHLG2E=.27ee84ba-00fd-405a-9489-8fe11c215af9@github.com>
 <21db5CiFTVN7scwsIHknMxF4YaVQd06m7gUOhcCLvMI=.e2f61ea7-bf9a-4632-bf45-c89f979ae806@github.com>
Message-ID: <sstOoZimEbZUq4NOh1i60YrMZveKZgxjblRFuOp4n-I=.9f3477a0-795c-4b71-a2b8-de0d7bd1835a@github.com>

On Tue, 5 Mar 2024 17:40:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The implementation of `Win32ShellFolder2.compareTo` is inconsistent: there are cases where  
>> `a < b & b < c but a == c`  
>> which *violates its general contract*.
>> 
>> In particular, it happens for the personal folder (*Documents*) if it is listed *twice*: as a special and as a regular folder.
>> 
>> The evaluation performed by the submitter of the bug provided enough details to create a test, reproduce the problem and finally resolve it.
>> 
>> Without the fix, the regression test always fails:
>> 
>> a < b & b < c but a >= c
>> where
>>   a = C:\Users<user>\Documents(true)
>>   b = C:\Users<user>(false)
>>   c = C:\Users<user>\Documents(false)
>> 
>> as well as for the reverse case: `a > b & b > c`.
>> 
>> How it is possible to have the same folder in a list of files twice remains unknown. I believe it is another bug in JDK, however, no one has been able to reproduce it so far.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handle fakePersonal on Windows 10
>   
>   The desktop folder on Windows 10 does not include
>   the Personal (Documents) folder.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18126#pullrequestreview-1987018502

From prr at openjdk.org  Mon Apr  8 23:22:00 2024
From: prr at openjdk.org (Phil Race)
Date: Mon, 8 Apr 2024 23:22:00 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS
In-Reply-To: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
References: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
Message-ID: <9NaQ7MzCph2B2CYYqk_o_yMqLtOz45sWsq8fbCk67Es=.d278e2e4-2dfe-499f-913f-b7ec47e577b9@github.com>

On Mon, 11 Mar 2024 13:54:02 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> The fix provides ability to print Black & White pages on macOS.
> 
> Cocoa API has [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode) function but it is marked as deprecated and really does nothing.
> 
> There is no replacement; this function was included to facilitate porting legacy applications to macOS, 
> but it serves no useful purpose.
> 
> Dumping `NSPrintInfo` print settings which were set by the native print dialog on macOS shows that the keys and values used for Black & White printing depend on the used printer type.
> For example, the tested 
> `HP Color LaserJet MFP M180n` printer uses `ColorModel` key and`Gray` value, and
> `HP Ink Tank 110 series` uses `HPColorMode` key and `grayscale` value.
> 
> Printing all `NSPrintInfo` presets shows that they do not contain key/value pairs  for Black&White settings.
> This is the code snippet used to print `NSPrintInfo` presets:
> 
>     PMPrinter pr;
>     PMPrintSession printSession = (PMPrintSession)[printInfo PMPrintSession];
>     OSStatus status = PMSessionGetCurrentPrinter(printSession, &pr);
>     CFArrayRef presetsList = nil;
>     status = PMPrinterCopyPresets(pr, &presetsList);
>     CFIndex arrayCount = CFArrayGetCount(presetsList);
> 
>     for (CFIndex index = 0; index < arrayCount; index++) {
>         PMPreset preset = (PMPreset)CFArrayGetValueAtIndex(presetsList, index);
>         CFStringRef presetName = nil;
>         if (PMPresetCopyName(preset, &presetName) == noErr && CFStringGetLength(presetName) > 0) {
>             NSLog(@"  presetName: '%@'", presetName);
>             NSDictionary* dict = nil;
>             if (PMPresetGetAttributes(preset, (CFDictionaryRef*)(&dict)) == noErr) {
>                    // print preset dict
> 
> 
> The idea of the proposed fix is to store printer dependent key/value pairs in the `<jdk-home>/conf/printer.properties` property file.
> 
> The property file has the format:
> 
> print-attribute.print-attribute-value.key=value
> 
> where `print-attribute` is the java print attribute, `print-attribute-value` is the corresponding attribute value, and `key` and `value` is the key/value pair used by a specific printer.
> 
> For example, for `Chromaticity` attribute the property file could look like:
> 
> Chromaticity.MONOCHROME.ColorModel=Gray
> Chromaticity.COLOR.ColorModel=CMYK
> Chromaticity.MONOCHROME.HPColorMode=grayscale
> Chromaticity.COLOR.HPColorMode=color
> 
> where `Chromaticity.MONOCHROME` key prefix corresponds to `Chromaticity.MONOCHOROME` print attribute constant  with  (...

Since the user can always select greyscale in the user dialog, I presume you have some requirement
to do this printing without user intervention. Perhaps there's no user there (server-side printing), or
the app would like to make sure the user always defaults to B&W.

As far as I can tell, this isn't supported via any kind of API on macOS, so it is not a Java problem.
You could be printing from an Objective-C app written directly to Cocoa APIs and still have the same problem.
So a Java-specific workaround like this seems inappropriate.

I've poked around to help me understand what is going on.

When I do "Print to File" on macOS - meaning use the native printer dialog's "Save as PDF" option,
then the generated PDF is always colour even if I select the printer dialog's "Grayscale Printing" option.
This isn't just true for Java apps, the same happens if I print a web page from Safari.

And when I query the  Chromaticity support for a couple of colour printers - one Canon, one HP,
both report they support it but only the value COLOR.

So I conclude the grayscale printing option is something handled by the printer driver at the time it is converted to
the printer-specific format and sent to the physical printer and it isn't changing the rendering.

So in general without an API, to get greyscale it requires the end-user to set an option in a print dialog
and as mentioned above, what you are trying  o enable isn't possible even if you wrote the app in
Objective-C or Swift directly as a macOS native app.

But what works for me to get greyscale by default is to set that up as the default for the print queue.
It is easy to add a printer twice - with two queues for it.
One has the default set to greyscale, the other to colour. Then the app just needs to select the required queue.
This is clearly more site-specific than having the app just specify MONOCHROME but is a lot lower cost all round.

I don't understand why PMSetColorMode is deprecated and non-functional since it seems like it would
be the right option here, but then internally macOS would need to be able to map it to the right option.
Doubtless that would be easier if MONOCHROME were supported by all these drivers and I don't understand
that omission either. In fact if it were we probably could just specify that directly without macOS needing
to understand anything - like  I expect it doesn't understand the key/value pairs your code is sending it.
I note that you send ALL known key/value pairs and hope one works .. and that points out that all
it takes is some vendor API change or a different printer and it just won't work again.
These points and the implied maintenance cost are some of my bigger concerns with this.

Perhaps you should engage with Apple and get them to properly support MONOCHROME.
Or maybe it would be enough if the printer vendors do ?
FWIW, I don't think it is an Apple-specific issue, the free drivers for Linux behave similarly.
Perhaps there's a clue in there somewhere. But similarly you can set up a separate queue.

The other idea that crossed my mind is that instead of relying on a printing solution, we could
explicitly render in greyscale. Then we could always declare MONOCHROME support and just emulate it.
But I am not sure if this is really possible - it would require changes to the rendering code and
I'm not sure if or how if we'd be able to do that properly and safely. And the risks of that clearly extend beyond printing.

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

PR Comment: https://git.openjdk.org/jdk/pull/18195#issuecomment-2043813832

From aivanov at openjdk.org  Tue Apr  9 11:45:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Apr 2024 11:45:12 GMT
Subject: Integrated: 8329761: Remove unused KeyBuilder and unusedSets from
 StyleContext
In-Reply-To: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
References: <fSDQeTqMNW8nwE2yaXmkmNla3vTEwhIOJJgPh0ydX94=.ab359b3e-b973-427c-ad49-3eb47ba7226b@github.com>
Message-ID: <1MpJ-gqrJZ6JUkKsCGgH60C5GFXuJfvvJwNWJPp4ZQ8=.b76ecbbc-e858-4c1e-a186-6e32bb97f9ef@github.com>

On Fri, 5 Apr 2024 15:46:06 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Remove unused class `KeyBuilder` and unused field `unusedSets`.  
> Update a comment which used javadoc syntax.  
> Mark `KeyEnumeration` and `FontKey` classes as *`final`*.
> 
> All the client tests are green.

This pull request has now been integrated.

Changeset: a48289ac
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a48289ac30a6a9ddc9941676726d105b11689ab3
Stats:     156 lines in 1 file changed: 0 ins; 150 del; 6 mod

8329761: Remove unused KeyBuilder and unusedSets from StyleContext

Reviewed-by: serb, tr

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

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

From aivanov at openjdk.org  Tue Apr  9 13:22:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Apr 2024 13:22:07 GMT
Subject: Integrated: 8305072: Win32ShellFolder2.compareTo is inconsistent
In-Reply-To: <bEiHvkFnBZDqmiqQdk_-_mATVhDbAD7NZX7VnkHLG2E=.27ee84ba-00fd-405a-9489-8fe11c215af9@github.com>
References: <bEiHvkFnBZDqmiqQdk_-_mATVhDbAD7NZX7VnkHLG2E=.27ee84ba-00fd-405a-9489-8fe11c215af9@github.com>
Message-ID: <fwymdIh73mBtepTxNglBM7hhCM6UbXJROLi07seerdg=.4435c4d1-cdf4-4b32-a7c4-36f2b262c440@github.com>

On Tue, 5 Mar 2024 17:01:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The implementation of `Win32ShellFolder2.compareTo` is inconsistent: there are cases where  
> `a < b & b < c but a == c`  
> which *violates its general contract*.
> 
> In particular, it happens for the personal folder (*Documents*) if it is listed *twice*: as a special and as a regular folder.
> 
> The evaluation performed by the submitter of the bug provided enough details to create a test, reproduce the problem and finally resolve it.
> 
> Without the fix, the regression test always fails:
> 
> a < b & b < c but a >= c
> where
>   a = C:\Users<user>\Documents(true)
>   b = C:\Users<user>(false)
>   c = C:\Users<user>\Documents(false)
> 
> as well as for the reverse case: `a > b & b > c`.
> 
> How it is possible to have the same folder in a list of files twice remains unknown. I believe it is another bug in JDK, however, no one has been able to reproduce it so far.

This pull request has now been integrated.

Changeset: 2fcb8168
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fcb816858406f33cefef3164b2c85f9f996c7da
Stats:     160 lines in 2 files changed: 158 ins; 0 del; 2 mod

8305072: Win32ShellFolder2.compareTo is inconsistent

Reviewed-by: prr, serb

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

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

From aivanov at openjdk.org  Tue Apr  9 14:00:06 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Apr 2024 14:00:06 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v2]
In-Reply-To: <xsB-qrz5sW5_KikA0CGqjv909VezEsThw9J2gqORHPE=.b698d508-8c2a-4825-977a-7af8c69b762e@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
 <xsB-qrz5sW5_KikA0CGqjv909VezEsThw9J2gqORHPE=.b698d508-8c2a-4825-977a-7af8c69b762e@github.com>
Message-ID: <EwU1xX90xhszKj75pnyQjCcqiI2JQB1dXXPLLdoJIUM=.549c040d-02f1-489e-b675-da227d1dc19c@github.com>

On Tue, 2 Apr 2024 16:58:19 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
>> 
>> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
>> 
>> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
>> 
>> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**
>
> Larry Cable has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into 8321428
>  - added deprecation message to package-info as requested
>  - 8321428: Deprecate for removal the package java.beans.beancontext

Should the copyright year be bumped to 2024 in all the modified files?

src/java.desktop/share/classes/java/beans/Beans.java line 106:

> 104:      * @since 1.2
> 105:      */
> 106:     @Deprecated(since = "23", forRemoval = true)

In other places, you didn't add spaces around `=` and used the reversed order of `since` and `forRemoval` attributes.

In majority of other files in this PR, `@SuppressWarnings` precedes `@Deprecated`.

src/java.desktop/share/classes/java/beans/beancontext/BeanContextChild.java line 69:

> 67: 
> 68: @SuppressWarnings("removal")
> 69: @Deprecated(forRemoval=true, since="23")

Suggestion:

@Deprecated(since="23", forRemoval=true)

The most common order of attributes in JDK is `since` followed by `forRemoval`. Should this package be consistent with other deprecated classes?

https://github.com/openjdk/jdk/blob/5fb5e6c8f04e325cbb782431d51251edde4c2618/src/java.base/share/classes/java/lang/Double.java#L1017-L1019

https://github.com/openjdk/jdk/blob/71c5bbcec7052a8394dd49c0a8c46801adbfcae4/src/java.base/share/classes/java/lang/SecurityManager.java#L316-L317

src/java.desktop/share/classes/java/beans/beancontext/package-info.java line 41:

> 39:  * Users are advised to migrate their applications to other technologies.
> 40:  *
> 41:  * @since 1.2

Is is possible to add `@Deprecated` annotation to the package?

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

PR Comment: https://git.openjdk.org/jdk/pull/18569#issuecomment-2045243209
PR Review Comment: https://git.openjdk.org/jdk/pull/18569#discussion_r1557661383
PR Review Comment: https://git.openjdk.org/jdk/pull/18569#discussion_r1557664034
PR Review Comment: https://git.openjdk.org/jdk/pull/18569#discussion_r1557656116

From prr at openjdk.org  Tue Apr  9 17:31:10 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Apr 2024 17:31:10 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
Message-ID: <rzNlwAz4Hmste23BOTQjMaaHbOdMyv3blZ43IWplRHs=.ebfad1ab-0326-468d-84b5-e647e5afdd63@github.com>

On Fri, 29 Mar 2024 15:32:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
> 
> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
> 
> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
> 
> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
> 
> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
> 
> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
> 
> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
> 
> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.

src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 3446:

> 3444:             @Override
> 3445:             void convertAttributes(HTML.Tag t, MutableAttributeSet attr) {
> 3446:                 Object newDecoration = attr.getAttribute(CSS.Attribute.TEXT_DECORATION);

parameter 't' isn't used. Why is that ?

test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 62:

> 60:             <p><span style='text-decoration: underline'><s>underline + line-through?</s></span></p>
> 61:             <p><span style='text-decoration: underline'><strike>underline + line-through?</strike></span></p>
> 62: 

Suppose there's this HTML
<p><s><span style='text-decoration: line-through'>underline + line-through?</span></s></p>


ie a strike through is specified in both ways. Does the merge code handle that ? I think it probably does but
adding this case to the test might be a good idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558054512
PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558056469

From honkar at openjdk.org  Tue Apr  9 18:44:09 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 9 Apr 2024 18:44:09 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
Message-ID: <iJs-baXmf3_GrOssK-IZaVStA5fk3gJyJzV6R0DAyBM=.8eae9fd0-0f91-481e-88c1-4213f9a25287@github.com>

On Fri, 29 Mar 2024 15:32:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
> 
> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
> 
> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
> 
> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
> 
> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
> 
> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
> 
> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
> 
> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.

test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 90:

> 88:             <div class="lineThrough"><p class="underline">underline + line-through?</p></div>
> 89: 
> 90:             <div class="underline"><div class="lineThrough">underline + line-through?</div></div>

The test fails when multiple CSS classes are on the same tag. Are we considering such cases as part of this fix?

For instance `<div class="underline lineThrough">This text should be striken</div>`
When testing on a normal HTML editor, the 1st class - underline is overriden and lineThrough is applied since both are related to text-decoration 
But when tested using HTMLTestDecoration.java it is not striken as expected.

For example: 

<!DOCTYPE html>
<html lang="en">
   <head>
      <meta charset="UTF-8">
      <title>underline + line-through text</title>
      <style>
         .underline   { text-decoration: underline }
         .lineThrough { text-decoration: line-through }
      </style>
   </head>
   <body>
      <div class="underline lineThrough">This text should be striken</div>
   </body>
</html>

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558128238

From prr at openjdk.org  Tue Apr  9 19:12:34 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Apr 2024 19:12:34 GMT
Subject: RFR: 8328896: Fontmetrics for large Fonts has zero width
Message-ID: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>

The main problem here is that we do not curate what font point size we passed to freetype,
and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
values, so 32767 is really the max.
But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
And we can request bigger sizes than that by making use of the transform.
At normal size ranges we use that just to account for rotation and decompose the glyph transform
into point size and that rotation.

But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
from not specifying the target point size. So we can extend the range of sizes we allow.

If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
a for a NaN transform.

These extreme values aren't useful.

In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
for rendering. Which is not useful and could lead to inconsistent results. I fixed that.

Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.

The test is mainly around making sure that "sensible" things are returned for not sensible input.
There's no 100% right answer to these extreme unrenderable sizes.

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

Commit messages:
 - 8328896
 - 8328896
 - 8328896

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

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

From aturbanov at openjdk.org  Tue Apr  9 19:12:34 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 9 Apr 2024 19:12:34 GMT
Subject: RFR: 8328896: Fontmetrics for large Fonts has zero width
In-Reply-To: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
References: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
Message-ID: <appa42VDx5-6t4HByjTBu6pxs-olAV4fGxwMMqhXmCs=.f37f8f88-7605-4cd7-9411-64793ba9fb37@github.com>

On Tue, 9 Apr 2024 18:50:17 GMT, Phil Race <prr at openjdk.org> wrote:

> The main problem here is that we do not curate what font point size we passed to freetype,
> and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
> This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
> But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
> values, so 32767 is really the max.
> But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
> And we can request bigger sizes than that by making use of the transform.
> At normal size ranges we use that just to account for rotation and decompose the glyph transform
> into point size and that rotation.
> 
> But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
> from not specifying the target point size. So we can extend the range of sizes we allow.
> 
> If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
> a for a NaN transform.
> 
> These extreme values aren't useful.
> 
> In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
> for rendering. Which is not useful and could lead to inconsistent results. I fixed that.
> 
> Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.
> 
> The test is mainly around making sure that "sensible" things are returned for not sensible input.
> There's no 100% right answer to these extreme unrenderable sizes.

src/java.desktop/share/classes/sun/font/FileFontStrike.java line 707:

> 705:                 Rectangle bds = getGlyphOutline(glyphCode, pt.x, pt.y).getBounds();
> 706:                 result.setBounds(bds);
> 707:             }  else {

Suggestion:

            } else {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18703#discussion_r1558154053

From honkar at openjdk.org  Tue Apr  9 19:13:10 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 9 Apr 2024 19:13:10 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
Message-ID: <mColaZucXknqYq9vqJifNo4B1hfT-_rjnbRZtACgZQ0=.fbb08469-5365-46cb-895b-794ac951aab3@github.com>

On Fri, 29 Mar 2024 15:32:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
> 
> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
> 
> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
> 
> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
> 
> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
> 
> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
> 
> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
> 
> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.

test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 125:

> 123:                     contentView.getAttributes()
> 124:                                .getAttribute(CSS.Attribute.TEXT_DECORATION)
> 125:                                .toString();

It might be good to add a null check before calling .toString() since `contentView.getAttributes().getAttribute(CSS.Attribute.TEXT_DECORATION)` can return null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558161327

From aivanov at openjdk.org  Tue Apr  9 20:12:09 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Apr 2024 20:12:09 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <rzNlwAz4Hmste23BOTQjMaaHbOdMyv3blZ43IWplRHs=.ebfad1ab-0326-468d-84b5-e647e5afdd63@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <rzNlwAz4Hmste23BOTQjMaaHbOdMyv3blZ43IWplRHs=.ebfad1ab-0326-468d-84b5-e647e5afdd63@github.com>
Message-ID: <h3dTRyz3JUSu1ur1NOfyUZ1QnwRlo4-eH4y8JvjtAb4=.2af50d36-3485-4f53-b3d6-5233d718ce22@github.com>

On Tue, 9 Apr 2024 17:27:57 GMT, Phil Race <prr at openjdk.org> wrote:

>> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
>> 
>> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
>> 
>> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
>> 
>> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
>> 
>> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
>> 
>> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
>> 
>> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
>> 
>> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.
>
> test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 62:
> 
>> 60:             <p><span style='text-decoration: underline'><s>underline + line-through?</s></span></p>
>> 61:             <p><span style='text-decoration: underline'><strike>underline + line-through?</strike></span></p>
>> 62: 
> 
> Suppose there's this HTML
> <p><s><span style='text-decoration: line-through'>underline + line-through?</span></s></p>
> 
> 
> ie a strike through is specified in both ways. Does the merge code handle that ? I think it probably does but
> adding this case to the test might be a good idea.

Because you didn't add the backticks <code>`</code> around your sample, it's interpreted as HTML, and I can't really see it.

If the both tags have the same value for the `text-decoration` property, it works without the fix. I'm sure it works with the fix, however, in some cases the value of the property may be `line-through,line-through`.

I'll add another test if you think such a scenario is worth verifying too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558227477

From aivanov at openjdk.org  Tue Apr  9 20:15:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Apr 2024 20:15:10 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <rzNlwAz4Hmste23BOTQjMaaHbOdMyv3blZ43IWplRHs=.ebfad1ab-0326-468d-84b5-e647e5afdd63@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <rzNlwAz4Hmste23BOTQjMaaHbOdMyv3blZ43IWplRHs=.ebfad1ab-0326-468d-84b5-e647e5afdd63@github.com>
Message-ID: <f0KFrgZc07sK5gLUqed31zhpTrQIIBL09YlC_NV-tZA=.40462664-637d-4b64-9e58-f6c7147a8358@github.com>

On Tue, 9 Apr 2024 17:26:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
>> 
>> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
>> 
>> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
>> 
>> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
>> 
>> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
>> 
>> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
>> 
>> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
>> 
>> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.
>
> src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java line 3446:
> 
>> 3444:             @Override
>> 3445:             void convertAttributes(HTML.Tag t, MutableAttributeSet attr) {
>> 3446:                 Object newDecoration = attr.getAttribute(CSS.Attribute.TEXT_DECORATION);
> 
> parameter 't' isn't used. Why is that ?

Because `ConvertSpanAction` is used for `HTML.Tag.SPAN` only:

https://github.com/openjdk/jdk/blob/e9cf30b3b31b50db8371bb7fdbfc2d68aacbb7da/src/java.desktop/share/classes/javax/swing/text/html/HTMLDocument.java#L2502

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558230493

From aivanov at openjdk.org  Tue Apr  9 20:19:09 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Apr 2024 20:19:09 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <iJs-baXmf3_GrOssK-IZaVStA5fk3gJyJzV6R0DAyBM=.8eae9fd0-0f91-481e-88c1-4213f9a25287@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <iJs-baXmf3_GrOssK-IZaVStA5fk3gJyJzV6R0DAyBM=.8eae9fd0-0f91-481e-88c1-4213f9a25287@github.com>
Message-ID: <snWxj61pdQZkPPw879VA7MsORKOZTQUFU530nKjHQfQ=.6a67554b-4b09-4cdf-8a3a-9595f287a7d8@github.com>

On Tue, 9 Apr 2024 18:36:46 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
>> 
>> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
>> 
>> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
>> 
>> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
>> 
>> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
>> 
>> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
>> 
>> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
>> 
>> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.
>
> test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 90:
> 
>> 88:             <div class="lineThrough"><p class="underline">underline + line-through?</p></div>
>> 89: 
>> 90:             <div class="underline"><div class="lineThrough">underline + line-through?</div></div>
> 
> The test fails when multiple CSS classes are on the same tag. Are we considering such cases as part of this fix?
> 
> For instance `<div class="underline lineThrough">This text should be striken</div>`
> When testing on a normal HTML editor, the 1st class - underline is overriden and lineThrough is applied since both are related to text-decoration.
> But when tested using HTMLTestDecoration.java it is not striken as expected.
> 
> For example: 
> 
> <!DOCTYPE html>
> <html lang="en">
>    <head>
>       <meta charset="UTF-8">
>       <title>underline + line-through text</title>
>       <style>
>          .underline   { text-decoration: underline }
>          .lineThrough { text-decoration: line-through }
>       </style>
>    </head>
>    <body>
>       <div class="underline lineThrough">This text should be striken</div>
>    </body>
> </html>

I'm pretty sure there are other cases where `text-decoration` isn't resolved correctly. It is not a goal to resolve all of the possible issues.

I'll check whether this scenario can be handled easily. I don't think it is. If not, I'll submit another bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558234784

From prr at openjdk.org  Tue Apr  9 20:27:09 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 9 Apr 2024 20:27:09 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <h3dTRyz3JUSu1ur1NOfyUZ1QnwRlo4-eH4y8JvjtAb4=.2af50d36-3485-4f53-b3d6-5233d718ce22@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <rzNlwAz4Hmste23BOTQjMaaHbOdMyv3blZ43IWplRHs=.ebfad1ab-0326-468d-84b5-e647e5afdd63@github.com>
 <h3dTRyz3JUSu1ur1NOfyUZ1QnwRlo4-eH4y8JvjtAb4=.2af50d36-3485-4f53-b3d6-5233d718ce22@github.com>
Message-ID: <TMZTFEY9S_o48klI0nAqKRg7tBvBJZlmpUNbn3WvrKo=.8ea84ab0-c41b-4b5c-8919-7c904a7759bd@github.com>

On Tue, 9 Apr 2024 20:09:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 62:
>> 
>>> 60:             <p><span style='text-decoration: underline'><s>underline + line-through?</s></span></p>
>>> 61:             <p><span style='text-decoration: underline'><strike>underline + line-through?</strike></span></p>
>>> 62: 
>> 
>> Suppose there's this HTML
>> `<p><s><span style='text-decoration: line-through'>underline + line-through?</span></s></p>`
>> 
>> 
>> ie a strike through is specified in both ways. Does the merge code handle that ? I think it probably does but
>> adding this case to the test might be a good idea.
>
> Because you didn't add the backticks <code>`</code> around your sample, it's interpreted as HTML, and I can't really see it.
> 
> I guess, the code was something line this: `<span style='text-decoration: line-through'><s>`.
> 
> If the both tags have the same value for the `text-decoration` property, it works without the fix. I'm sure it works with the fix, however, in some cases the value of the property may be `line-through,line-through`.
> 
> I'll add another test if you think such a scenario is worth verifying too.

I added the backticks so it now shows the source but all I did was "s/<u>/s/"

Yes, I think it might be wise to add such a test scenario.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558243682

From aivanov at openjdk.org  Tue Apr  9 20:27:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 9 Apr 2024 20:27:10 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <mColaZucXknqYq9vqJifNo4B1hfT-_rjnbRZtACgZQ0=.fbb08469-5365-46cb-895b-794ac951aab3@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <mColaZucXknqYq9vqJifNo4B1hfT-_rjnbRZtACgZQ0=.fbb08469-5365-46cb-895b-794ac951aab3@github.com>
Message-ID: <5aNyTM5p2bKf5ixLuSpN41AI2sONe9BFqa4W2ooKneI=.18ee129e-9fd8-42d2-8d87-3c8ecede8121@github.com>

On Tue, 9 Apr 2024 19:10:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
>> 
>> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
>> 
>> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
>> 
>> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
>> 
>> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
>> 
>> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
>> 
>> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
>> 
>> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.
>
> test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 125:
> 
>> 123:                     contentView.getAttributes()
>> 124:                                .getAttribute(CSS.Attribute.TEXT_DECORATION)
>> 125:                                .toString();
> 
> It might be good to add a null check before calling .toString() since `contentView.getAttributes().getAttribute(CSS.Attribute.TEXT_DECORATION)` can return null.

No, it can't. In the test, all the views that end up in `contentView` must have the `CSS.Attribute.TEXT_DECORATION` attribute and its value must contain both `underline` and `line-through`. It is what the test verifies.

If the test is modified and `contentView` does not have the `CSS.Attribute.TEXT_DECORATION` attribute, the test will fail with `NullPointerException` which is fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558240319

From honkar at openjdk.org  Tue Apr  9 21:02:11 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 9 Apr 2024 21:02:11 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <snWxj61pdQZkPPw879VA7MsORKOZTQUFU530nKjHQfQ=.6a67554b-4b09-4cdf-8a3a-9595f287a7d8@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <iJs-baXmf3_GrOssK-IZaVStA5fk3gJyJzV6R0DAyBM=.8eae9fd0-0f91-481e-88c1-4213f9a25287@github.com>
 <snWxj61pdQZkPPw879VA7MsORKOZTQUFU530nKjHQfQ=.6a67554b-4b09-4cdf-8a3a-9595f287a7d8@github.com>
Message-ID: <el5-1yFy-gZLBjTDYgJgYwS41s1L-j7J2SVlhZFnI7Q=.f30c428d-35d8-4c95-a64e-85267187bb6d@github.com>

On Tue, 9 Apr 2024 20:16:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/javax/swing/text/html/HTMLDocument/HTMLTextDecoration.java line 90:
>> 
>>> 88:             <div class="lineThrough"><p class="underline">underline + line-through?</p></div>
>>> 89: 
>>> 90:             <div class="underline"><div class="lineThrough">underline + line-through?</div></div>
>> 
>> The test fails when multiple CSS classes are on the same tag. Are we considering such cases as part of this fix?
>> 
>> For instance `<div class="underline lineThrough">This text should be striken</div>`
>> When testing on a normal HTML editor, the 1st class - underline is overriden and lineThrough is applied since both are related to text-decoration.
>> But when tested using HTMLTestDecoration.java it is not striken as expected.
>> 
>> For example: 
>> 
>> <!DOCTYPE html>
>> <html lang="en">
>>    <head>
>>       <meta charset="UTF-8">
>>       <title>underline + line-through text</title>
>>       <style>
>>          .underline   { text-decoration: underline }
>>          .lineThrough { text-decoration: line-through }
>>       </style>
>>    </head>
>>    <body>
>>       <div class="underline lineThrough">This text should be striken</div>
>>    </body>
>> </html>
>
> I'm pretty sure there are other cases where `text-decoration` isn't resolved correctly. It is not a goal to resolve all of the possible issues.
> 
> I'll check whether this scenario can be handled easily. I don't think it is. If not, I'll submit another bug.

Sounds good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1558283742

From tr at openjdk.org  Wed Apr 10 04:37:31 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 04:37:31 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
Message-ID: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>

Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

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

Commit messages:
 - Updated with null check
 - Fix

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

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

From tr at openjdk.org  Wed Apr 10 04:43:29 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 04:43:29 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>

> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.

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

 - Copywrite year updated
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8322140
 - Spacing updates
 - Updated test with BugID and copyright year
 - Fix + Revert 8210807

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18187/files
  - new: https://git.openjdk.org/jdk/pull/18187/files/41fcb586..3dfb3120

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

  Stats: 388382 lines in 3437 files changed: 33990 ins; 26758 del; 327634 mod
  Patch: https://git.openjdk.org/jdk/pull/18187.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18187/head:pull/18187

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

From tr at openjdk.org  Wed Apr 10 04:43:30 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 04:43:30 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v2]
In-Reply-To: <6H0X5J1HCpgp5QaaTmI-eRFulcSzH38Rm1ETsJd4F0k=.82dd9a37-8c35-42f9-8d4b-e6aad6392d6c@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <WdIr-XJAfVq7KOMVFjJfj7ObW-itoexFlcd75x302EE=.c1f35956-1e62-4c51-8d14-c13a2cf7c758@github.com>
 <6H0X5J1HCpgp5QaaTmI-eRFulcSzH38Rm1ETsJd4F0k=.82dd9a37-8c35-42f9-8d4b-e6aad6392d6c@github.com>
Message-ID: <UHZ809I2PMX0AQ3It9MbT4UMuxrns5INt-58UNcxhXQ=.a9a00595-9781-4218-b1a1-ceb6450de11f@github.com>

On Mon, 8 Apr 2024 09:42:10 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Spacing updates
>>  - Updated test with BugID and copyright year
>
> test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, 2014, Oracle and/or its affiliates. All rights reserved.
> 
> should be 2024

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1558831427

From psadhukhan at openjdk.org  Wed Apr 10 05:02:11 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 10 Apr 2024 05:02:11 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
Message-ID: <Q3cd9GJmzFCcTZIIoJ30yB4XIMxWV4eSovd0PX0TL0g=.b23ef9a8-9ca1-4428-8ec1-b3371ecdb3ba@github.com>

On Wed, 10 Apr 2024 04:43:29 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.
>
> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Copywrite year updated
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8322140
>  - Spacing updates
>  - Updated test with BugID and copyright year
>  - Fix + Revert 8210807

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18187#pullrequestreview-1990795930

From abhiscxk at openjdk.org  Wed Apr 10 05:25:37 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 05:25:37 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v8]
In-Reply-To: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
Message-ID: <V1NMUh460PcWjvbl83QcEdb99Dqy6MRABi9-eQao1M8=.8f4aa003-f8e3-4aa6-90e1-64eb6a6475a2@github.com>

> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
> 
> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
> 
> CI link is posted in JBS.

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

  Tabs Opaque checkbox handle in synth derived lafs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17720/files
  - new: https://git.openjdk.org/jdk/pull/17720/files/250fe3af..066b5fd6

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

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

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

From abhiscxk at openjdk.org  Wed Apr 10 05:32:09 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 05:32:09 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v7]
In-Reply-To: <AiDLz1rlEahkR-9yVHchm5VOU4MwqLHv0XMU4vwEJbo=.8ad84fc2-4a97-4b88-844d-a29f6322117e@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <ZpAg5O62YXygopX-9xFLj6OnBEkc-suTdGNljVJg3EQ=.4e8ead36-5019-4f48-a6b1-b6f78e01a5a0@github.com>
 <AiDLz1rlEahkR-9yVHchm5VOU4MwqLHv0XMU4vwEJbo=.8ad84fc2-4a97-4b88-844d-a29f6322117e@github.com>
Message-ID: <ihdxkAZXCBIUlh9Px2oeCl6n_o4P0AZOoFvxCxJNuCw=.bde400b3-77e9-485d-ac49-71461badfec0@github.com>

On Thu, 4 Apr 2024 17:10:45 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/GTKLookAndFeel.java line 1026:
> 
>> 1024:             "TabbedPane.selected", tabbedPaneBg,
>> 1025:             "TabbedPane.contentOpaque", Boolean.TRUE,
>> 1026:             "TabbedPane.contentAreaColor", tabbedPaneBg,
> 
> `TabbedPane.contentOpaque` and `TabbedPane.tabsOpaque` seems to go hand-in-hand and there's another issue for it https://bugs.openjdk.org/browse/JDK-6462396 so if we are supporting one and not other, it may not have desired effect..

@prsadhuk Handled the `TabbedPane.tabsOpaque` UI property for Synth derived LAFs. Test enhanced to check for `Content Opaque` and `Tabs Opaque` UI property behaviour. As mentioned in comment section of bug [JDK-6462396](https://bugs.openjdk.org/browse/JDK-6462396) `Note: These new properties are only honored if the JTabbedPane is non-opaque itself`, the properties are handled in same way for synth based LAFs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1558864784

From tr at openjdk.org  Wed Apr 10 07:14:10 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 07:14:10 GMT
Subject: Integrated: 8328482: Convert and Open source few manual applet test to
 main based
In-Reply-To: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
References: <aV9yYWUEsrakxmujJCq2LzFg5K6nyCV4aELge8c1oJo=.c9f2c13d-337f-4af3-8a38-551a7f0ba0c6@github.com>
Message-ID: <mNeHSNyhlvB7WpuRZR9-O3L32IhbyjrcQYJZ25zIhlQ=.387bafe8-f55a-4161-be32-5b631f5cd393@github.com>

On Fri, 22 Mar 2024 09:48:08 GMT, Tejesh R <tr at openjdk.org> wrote:

> Convert and open source these manual applet test to main based:
> java/awt/Frame/MegaIconTest/MegaIconTest.html
> java/awt/Frame/FrameMaximizedTest/FrameMaximizedTest.html
> java/awt/Frame/FrameMinimizeTest/FrameMinimizeTest.html
> java/awt/Frame/SizeMinimizedTest/SizeMinimizedTest.html
> 
> Automated the test SizeMinimizedTest.java. Since the test is failing Linux arch (Maybe related to the bug - [JDK-8305915](https://bugs.openjdk.org/browse/JDK-8305915)), the test is problem listed for Linux arch until the issue is fixed/further investigation is done.

This pull request has now been integrated.

Changeset: bea9acc5
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bea9acc55a7b0463a1b0b4dcb557f8ea17d8fe8c
Stats:     535 lines in 8 files changed: 535 ins; 0 del; 0 mod

8328482: Convert and Open source few manual applet test to main based

Reviewed-by: abhiscxk, honkar, prr

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

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

From abhiscxk at openjdk.org  Wed Apr 10 09:09:05 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 09:09:05 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
Message-ID: <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>

On Wed, 10 Apr 2024 04:43:29 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.
>
> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Copywrite year updated
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8322140
>  - Spacing updates
>  - Updated test with BugID and copyright year
>  - Fix + Revert 8210807

src/java.desktop/share/classes/sun/print/PathGraphics.java line 1149:

> 1147:     }
> 1148: 
> 1149:     public static BufferedImage convertToBufferedImage(MultiResolutionImage multiResolutionImage,

Probably the method should be declared as either `private` or `protected`, as adding a `public` method may need a CSR.

May not require to declare it as `static` too.

src/java.desktop/share/classes/sun/print/PathGraphics.java line 1155:

> 1153:                                                         resolutionImage.getHeight(null),
> 1154:                                                         BufferedImage.TYPE_INT_ARGB);
> 1155:         Graphics2D g2d = bufferedImage.createGraphics();

Should we dispose the Graphics2D obj ?

src/java.desktop/share/classes/sun/print/PathGraphics.java line 1156:

> 1154:                                                         BufferedImage.TYPE_INT_ARGB);
> 1155:         Graphics2D g2d = bufferedImage.createGraphics();
> 1156:         g2d.drawImage(resolutionImage, 0, 0, (int)width, (int)height, null);

Suggestion:

        g2d.drawImage(resolutionImage, 0, 0, (int) width, (int) height, null);

test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 45:

> 43:  * @test
> 44:  * @key headful
> 45:  * @bug 8210807 8322140

Suggestion:

You may update the test with `PassFailJFrame.builder()`.

I guess `Graphics2D g2d` object needs to be disposed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559094053
PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559095223
PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559095541
PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559106656

From tr at openjdk.org  Wed Apr 10 09:35:13 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 09:35:13 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
Message-ID: <CFLARDoBHkiJF1CJRdqby7UTbC3e3v_JfOiDFs_kZ8U=.04df190c-c0d1-462d-8e6a-0b6bdaf95215@github.com>

On Wed, 10 Apr 2024 08:57:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Copywrite year updated
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8322140
>>  - Spacing updates
>>  - Updated test with BugID and copyright year
>>  - Fix + Revert 8210807
>
> src/java.desktop/share/classes/sun/print/PathGraphics.java line 1155:
> 
>> 1153:                                                         resolutionImage.getHeight(null),
>> 1154:                                                         BufferedImage.TYPE_INT_ARGB);
>> 1155:         Graphics2D g2d = bufferedImage.createGraphics();
> 
> Should we dispose the Graphics2D obj ?

I'm not sure whether we have to dispose it here at this context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559141725

From abhiscxk at openjdk.org  Wed Apr 10 09:54:10 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 09:54:10 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <CFLARDoBHkiJF1CJRdqby7UTbC3e3v_JfOiDFs_kZ8U=.04df190c-c0d1-462d-8e6a-0b6bdaf95215@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
 <CFLARDoBHkiJF1CJRdqby7UTbC3e3v_JfOiDFs_kZ8U=.04df190c-c0d1-462d-8e6a-0b6bdaf95215@github.com>
Message-ID: <LiujYvh4uX1nFgautM3acIHBMwsNpqI3U4ZvgnefCII=.7cd70dd3-ef09-44d5-85dd-2e86e24344b8@github.com>

On Wed, 10 Apr 2024 09:32:42 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/print/PathGraphics.java line 1155:
>> 
>>> 1153:                                                         resolutionImage.getHeight(null),
>>> 1154:                                                         BufferedImage.TYPE_INT_ARGB);
>>> 1155:         Graphics2D g2d = bufferedImage.createGraphics();
>> 
>> Should we dispose the Graphics2D obj ?
>
> I'm not sure whether we have to dispose it here at this context.

Since you are creating it locally, I guess you can dispose it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559164403

From tr at openjdk.org  Wed Apr 10 10:02:12 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 10:02:12 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <LiujYvh4uX1nFgautM3acIHBMwsNpqI3U4ZvgnefCII=.7cd70dd3-ef09-44d5-85dd-2e86e24344b8@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
 <CFLARDoBHkiJF1CJRdqby7UTbC3e3v_JfOiDFs_kZ8U=.04df190c-c0d1-462d-8e6a-0b6bdaf95215@github.com>
 <LiujYvh4uX1nFgautM3acIHBMwsNpqI3U4ZvgnefCII=.7cd70dd3-ef09-44d5-85dd-2e86e24344b8@github.com>
Message-ID: <IbGbN_mrVj9_cq1DxpcFis3yOexuhXYpG3kx2Quhms0=.a302dd46-44fc-4544-8c53-7e106ad35594@github.com>

On Wed, 10 Apr 2024 09:51:05 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> I'm not sure whether we have to dispose it here at this context.
>
> Since you are creating it locally, I guess you can dispose it.

I'm sure whether a new Graphics2D object will be created or reference will be passed, just vaguely remember a conversation regarding disposing it and suggested not to dispose since a reference will be passed on. So not sure should we actually dispose here or not. And also I see in most of the places its not been disposed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559174493

From abhiscxk at openjdk.org  Wed Apr 10 10:30:10 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 10:30:10 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <IbGbN_mrVj9_cq1DxpcFis3yOexuhXYpG3kx2Quhms0=.a302dd46-44fc-4544-8c53-7e106ad35594@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
 <CFLARDoBHkiJF1CJRdqby7UTbC3e3v_JfOiDFs_kZ8U=.04df190c-c0d1-462d-8e6a-0b6bdaf95215@github.com>
 <LiujYvh4uX1nFgautM3acIHBMwsNpqI3U4ZvgnefCII=.7cd70dd3-ef09-44d5-85dd-2e86e24344b8@github.com>
 <IbGbN_mrVj9_cq1DxpcFis3yOexuhXYpG3kx2Quhms0=.a302dd46-44fc-4544-8c53-7e106ad35594@github.com>
Message-ID: <HRDlzR8kETgJP-Imd24PE88gGWXYhCTPc8u_fh08Gbg=.804a73b2-ade0-4586-a4c9-66c68506864a@github.com>

On Wed, 10 Apr 2024 09:59:19 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Since you are creating it locally, I guess you can dispose it.
>
> I'm sure whether a new Graphics2D object will be created or reference will be passed, just vaguely remember a conversation regarding disposing it and suggested not to dispose since a reference will be passed on. So not sure should we actually dispose here or not. And also I see in most of the places its not been disposed.

I guess you mentioned about this thread https://github.com/openjdk/jdk/pull/17609#discussion_r1483263329.
But here the graphics object is passed as parameter.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559207876

From tr at openjdk.org  Wed Apr 10 11:17:12 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 11:17:12 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <HRDlzR8kETgJP-Imd24PE88gGWXYhCTPc8u_fh08Gbg=.804a73b2-ade0-4586-a4c9-66c68506864a@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
 <CFLARDoBHkiJF1CJRdqby7UTbC3e3v_JfOiDFs_kZ8U=.04df190c-c0d1-462d-8e6a-0b6bdaf95215@github.com>
 <LiujYvh4uX1nFgautM3acIHBMwsNpqI3U4ZvgnefCII=.7cd70dd3-ef09-44d5-85dd-2e86e24344b8@github.com>
 <IbGbN_mrVj9_cq1DxpcFis3yOexuhXYpG3kx2Quhms0=.a302dd46-44fc-4544-8c53-7e106ad35594@github.com>
 <HRDlzR8kETgJP-Imd24PE88gGWXYhCTPc8u_fh08Gbg=.804a73b2-ade0-4586-a4c9-66c68506864a@github.com>
Message-ID: <6LYqWSGfza_rb9_p2PLvmrw_1A2zDutc1--TQJa9Vek=.41f36058-861d-4b7d-86f0-5f310f89389b@github.com>

On Wed, 10 Apr 2024 10:27:03 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> I'm sure whether a new Graphics2D object will be created or reference will be passed, just vaguely remember a conversation regarding disposing it and suggested not to dispose since a reference will be passed on. So not sure should we actually dispose here or not. And also I see in most of the places its not been disposed.
>
> I guess you mentioned about this thread https://github.com/openjdk/jdk/pull/17609#discussion_r1483263329.
> But here the graphics object is passed as parameter.

Yeah right. Thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559261782

From abhiscxk at openjdk.org  Wed Apr 10 11:18:13 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 11:18:13 GMT
Subject: RFR: 8075917: The regression-swing case failed as the text on
 label is not painted red with the GTK L&F [v5]
In-Reply-To: <N1Kr4a0UVv-Wn5-LLP_lvDaeuuaXh_VUG2gO8EqueU8=.5d271c46-3a14-44bd-bf4a-c42c446f0e1a@github.com>
References: <iDOTnLkAimOa5kfDerZ09n4wsYiFYYUyBflOTYeUQZ0=.293390bd-bc47-4871-bf4c-d23c191d9426@github.com>
 <5eZ7a0HiqE3hghw3sT0L0Zn4Mi1FFfofz6hLGdLOsoc=.445b16ac-4d91-4538-92ba-a74f17781535@github.com>
 <8aBNZkw1dIeHg9WidHBtQnx1mtZbSs4fWqQFl0KFOnI=.ddbcc158-5cb7-4ad6-ace0-4ed41f4d9048@github.com>
 <N1Kr4a0UVv-Wn5-LLP_lvDaeuuaXh_VUG2gO8EqueU8=.5d271c46-3a14-44bd-bf4a-c42c446f0e1a@github.com>
Message-ID: <1WiIm7NiH5N9Z1P_u5pubMMIhCsH5cCIjYmAh1KG2Fg=.0f32c2ef-8cb6-4d5d-9e3d-42feee9b3c17@github.com>

On Tue, 26 Mar 2024 08:22:52 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> @aivanov-jdk 
>> 
>>> This looks weird? So you're saying Label[Enabled].textForeground and Label[Disabled].textForeground are used for Nimbus (and Synth and GTK) instead of Label.foreground and Label.disabledForeground which are used for other L&Fs.
>> 
>> As per my understanding, Yes, for Nimbus LAF the UI properties are different than other LAF.
>> 
>>> Shouldn't we fix the problem by correcting the keys instead? It looks like it's what you're doing for specific components.
>> 
>> I am not sure if it is a problem or nimbus LAF is supposed to be like this.
>> 
>>> Is it specified anywhere that Synth-based L&Fs use different constants? It results in incorrect colors.
>> 
>> Need to check on this.
>> 
>>> If a developer sets the common properties, should they override Look-and-Feel defaults?
>> 
>> Will check and revert back.
>
>> @aivanov-jdk
>> 
>> > This looks weird? So you're saying Label[Enabled].textForeground and Label[Disabled].textForeground are used for Nimbus (and Synth and GTK) instead of Label.foreground and Label.disabledForeground which are used for other L&Fs.
>> 
>> As per my understanding, Yes, for Nimbus LAF the UI properties are different than other LAF.
>> 
>> > Shouldn't we fix the problem by correcting the keys instead? It looks like it's what you're doing for specific components.
>> 
>> I am not sure if it is a problem or nimbus LAF is supposed to be like this.
>> 
>> > Is it specified anywhere that Synth-based L&Fs use different constants? It results in incorrect colors.
>> 
>> Need to check on this.
>> 
>> > If a developer sets the common properties, should they override Look-and-Feel defaults?
>> 
>> Will check and revert back.
> 
> 
> As I understood, what `Label.background` color to be set, is determined via **`Nimbus.Overrides`** property
> i.e.,  if `Label.background` is set to `Nimbus.Overrides`,  it should override the `label.setBackground()` user color setting 
> else 
> if `Nimbus.Overrides` is not set or set to null, then `Label.setBackground()` will hold precedent even if `Label.background` property is set
> 
> 
> Similarly, if `Nimbus.Overrides` is set with `Label.background` color **AND** Label[Enabled].background is also set,
> then 
> Label[Enabled].background will have priority over 
> Label.background which will have priority over
> Label.setBackground() 
> 
> but this is also controlled by another boolean property **`Nimbus.Overrides.InheritDefaults`** in way that the above precedence is valid only if if Nimbus.Overrides.InheritDefaults is true
> 
> if **`Nimbus.Overrides.InheritDefaults`** is false, then Label[Enabled].background will be ignored
> and
> Label.background will have priority over 
> Label.setBackground() 
> 
> This is somewhat explained in `https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/plaf/nimbus/package-summary.html` and tested in` test/jdk/javax/swing/plaf/nimbus/ColorCustomizationTest.java` so in a way, it seems widget[state].color setting is applicable for Nimbus only since we dont have GTK.Overrides property

@prsadhuk As we discussed earlier, I checked JLabel rendering in AquaLookAndFeel. Basically, `AquaLabelUI` class doesn't override the `installDefaults` method and so the `installDefaults` method of `BasicLabelUI` class is invoked which set the foreground, background and font property through LookAndFeel and which fetch them from UIManager property.

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

PR Comment: https://git.openjdk.org/jdk/pull/17763#issuecomment-2047258353

From tr at openjdk.org  Wed Apr 10 11:26:03 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 11:26:03 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
Message-ID: <NF7Bh05zwKIGzqUB_5KMgbNIYrc5MEPmUySaxjTJWrI=.cb7a5980-39b1-4ea3-a075-4ec6bdfb7b07@github.com>

On Wed, 10 Apr 2024 09:05:49 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Copywrite year updated
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8322140
>>  - Spacing updates
>>  - Updated test with BugID and copyright year
>>  - Fix + Revert 8210807
>
> test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 45:
> 
>> 43:  * @test
>> 44:  * @key headful
>> 45:  * @bug 8210807 8322140
> 
> Suggestion:
> 
> You may update the test with `PassFailJFrame.builder()`.
> 
> I guess `Graphics2D g2d` object needs to be disposed.

I guess here we don't have to dispose.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559271683

From abhiscxk at openjdk.org  Wed Apr 10 11:28:10 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 11:28:10 GMT
Subject: RFR: 8075917: The regression-swing case failed as the text on
 label is not painted red with the GTK L&F [v5]
In-Reply-To: <5eZ7a0HiqE3hghw3sT0L0Zn4Mi1FFfofz6hLGdLOsoc=.445b16ac-4d91-4538-92ba-a74f17781535@github.com>
References: <iDOTnLkAimOa5kfDerZ09n4wsYiFYYUyBflOTYeUQZ0=.293390bd-bc47-4871-bf4c-d23c191d9426@github.com>
 <5eZ7a0HiqE3hghw3sT0L0Zn4Mi1FFfofz6hLGdLOsoc=.445b16ac-4d91-4538-92ba-a74f17781535@github.com>
Message-ID: <OVRLAsylgErl0XhDvAXWQBe05BNk1O2pJDpKsTsKFWI=.7f8eef63-d596-43d8-9bc7-2e7dc3ef7424@github.com>

On Tue, 5 Mar 2024 05:28:01 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JLabel text is not painted with the LAF defined foreground color in GTK LAF. In GTK LAF the foreground color is retrieved by using native system APIs. Fix is to return the foreground color if it is set by LAF defined property otherwise return the default color by calling native APIs.
>> Applet based test has been converted to automatic test and check for all installed LAFs. CI testing is green for test suite and individual test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   separate method to get LAF defined color

In Nimbus and GTK LAF, these properties (foreground, background, font) are set via SynthStyle [installDefaults](https://github.com/kumarabhi006/jdk/blob/master/src/java.desktop/share/classes/javax/swing/plaf/synth/SynthStyle.java#L928) method where the foreground, background are set by getting the value from getColorForState method.

Moreover these properties (foreground, background, font) are not defined for Synth derived LAFs. One possible reason may be Nimbus properties are different from GTK (e.g. Label.foreground in GTK and Label[Enabled].textForeground in Nimbus).

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

PR Comment: https://git.openjdk.org/jdk/pull/17763#issuecomment-2047275612

From abhiscxk at openjdk.org  Wed Apr 10 11:49:09 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 10 Apr 2024 11:49:09 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
 <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
Message-ID: <4DSqkgpCCYcXFzbdFX8T4OK_0S3Jm84HU9Tt1Scdgj0=.fff962e0-50be-4d61-916e-3cf04cf932e5@github.com>

On Mon, 8 Apr 2024 07:57:11 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
>> 
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated insturction style
>  - Updated suggesions

Is there any way we can test it with "print to pdf" option or physical printer is must?

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

PR Comment: https://git.openjdk.org/jdk/pull/18624#issuecomment-2047314118

From tr at openjdk.org  Wed Apr 10 11:52:18 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 11:52:18 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
Message-ID: <1EPViPXOxCUcV6w47zULL0YJT5vMIimWyRBcnp71zOU=.397d4b19-acab-4f70-a783-b7493fc7d1fb@github.com>

On Wed, 10 Apr 2024 08:56:08 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Copywrite year updated
>>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into branch_8322140
>>  - Spacing updates
>>  - Updated test with BugID and copyright year
>>  - Fix + Revert 8210807
>
> src/java.desktop/share/classes/sun/print/PathGraphics.java line 1149:
> 
>> 1147:     }
>> 1148: 
>> 1149:     public static BufferedImage convertToBufferedImage(MultiResolutionImage multiResolutionImage,
> 
> Probably the method should be declared as either `private` or `protected`, as adding a `public` method may need a CSR.
> 
> May not require to declare it as `static` too.

Updated.

> src/java.desktop/share/classes/sun/print/PathGraphics.java line 1156:
> 
>> 1154:                                                         BufferedImage.TYPE_INT_ARGB);
>> 1155:         Graphics2D g2d = bufferedImage.createGraphics();
>> 1156:         g2d.drawImage(resolutionImage, 0, 0, (int)width, (int)height, null);
> 
> Suggestion:
> 
>         g2d.drawImage(resolutionImage, 0, 0, (int) width, (int) height, null);

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559300103
PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559299860

From tr at openjdk.org  Wed Apr 10 11:52:19 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 10 Apr 2024 11:52:19 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v3]
In-Reply-To: <NF7Bh05zwKIGzqUB_5KMgbNIYrc5MEPmUySaxjTJWrI=.cb7a5980-39b1-4ea3-a075-4ec6bdfb7b07@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <yFUJEZqlGHfpdb9qhjkb7rEYxZYhXH76r4sTk0P2wc8=.2186c369-b59e-4fdc-b36f-1649a1570219@github.com>
 <bOXlCpkn3zMLUyjRDGid_3WTGviDMvucANWSgvjpzQU=.c2f7497c-93e6-43d2-9e85-711d83de0a75@github.com>
 <NF7Bh05zwKIGzqUB_5KMgbNIYrc5MEPmUySaxjTJWrI=.cb7a5980-39b1-4ea3-a075-4ec6bdfb7b07@github.com>
Message-ID: <-YvDA8us9YfvW3WmqWPrSvpjxEUgMVOVxKJYG4ecTQ0=.aca4df54-347e-44a9-a0ce-a4e03773c225@github.com>

On Wed, 10 Apr 2024 11:23:22 GMT, Tejesh R <tr at openjdk.org> wrote:

>> test/jdk/javax/swing/JTable/JTableScrollPrintTest.java line 45:
>> 
>>> 43:  * @test
>>> 44:  * @key headful
>>> 45:  * @bug 8210807 8322140
>> 
>> Suggestion:
>> 
>> You may update the test with `PassFailJFrame.builder()`.
>> 
>> I guess `Graphics2D g2d` object needs to be disposed.
>
> I guess here we don't have to dispose.

Updated test with PassFailJFrame.builder().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18187#discussion_r1559299656

From aivanov at openjdk.org  Wed Apr 10 14:24:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 10 Apr 2024 14:24:18 GMT
Subject: Integrated: 8327137: Add test for ConcurrentModificationException in
 BasicDirectoryModel
In-Reply-To: <mCqqjrXVWDB2PvpOhKHx-Hr8W6tUz6v4stztGmyAeEg=.1f95da1c-e1a5-40be-be8b-0758729fa9b9@github.com>
References: <mCqqjrXVWDB2PvpOhKHx-Hr8W6tUz6v4stztGmyAeEg=.1f95da1c-e1a5-40be-be8b-0758729fa9b9@github.com>
Message-ID: <_kdK-6Gzwb753E4VMIWDEVsJsWza8tALielht0JCOzU=.bba9a95a-31de-409f-bdd9-5170ee5c7f0e@github.com>

On Mon, 4 Mar 2024 15:52:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> I'm adding a regression test for [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670) and [JDK-8307091](https://bugs.openjdk.org/browse/JDK-8307091); it's also a regression test for [JDK-8240690](https://bugs.openjdk.org/browse/JDK-8240690).
> 
> I referenced this test in PR #17462 in [this comment](https://github.com/openjdk/jdk/pull/17462#issuecomment-1914844026). I fine-tuned the test since that time.
> 
> The test doesn't fail all the time without the fix for JDK-8323670, however, it fails sometimes. If you run the test several times, it will likely fail _without the fix_.
> 
> For me, the test fails about 10 times from 40 runs in the CI. It fails on macOS more frequently than on Linux.
> 
> When the test passes, it usually completes in 5 minutes.
> 
> **How the test works**
> 
> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
> 
> The test starts several _scanner_ threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
> 
> A timer is used to create new files in the directory that the file chooser is using.
> 
> After enumerating the files, the File Loading Thread posts an event to EDT. The event updates `fileCache` and fires a `ListDataEvent`.
> 
> If the File Loading Thread is iterating over `fileCache` using `Iterator` (when `fileCache.subList` or `fileCache.equals` is running; or a new `Vector` instance is created from a `fileCache` or its sublist) and `fileCache` is being updated on EDT, then `ConcurrentModificationException` is thrown.
> 
> On Linux and on _headless_ macOS, `ShellFolder.invoke` is executed in the caller, which makes it easier to reproduce the issue. Because of [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179), there are several File Loading Threads, which also helps to reproduce the issue.
> 
> On _headful_ macOS, the `BasicDirectoryModel` is not used, so the test does not reproduce the issue.
> 
> On Windows, the test does not fail or fails with `OutOfMemoryError`. It is because all the File Loading Threads are serialised on the COM thread, `ShellFolder.invoke` submits the task to the COM thread and waits for it to complete. The chance of updating `fileCache` whil...

This pull request has now been integrated.

Changeset: 9731b1c8
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9731b1c8b02d957985f4fb40acd93fb67747a9f0
Stats:     273 lines in 1 file changed: 273 ins; 0 del; 0 mod

8327137: Add test for ConcurrentModificationException in BasicDirectoryModel

Reviewed-by: serb, tr

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

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

From duke at openjdk.org  Wed Apr 10 18:34:15 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 10 Apr 2024 18:34:15 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v3]
In-Reply-To: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
Message-ID: <4AfxDStsve821uE1vul8sYl_U1n50qZfEF1HWfmJT88=.a5afd9b6-05a3-478f-a0a6-348b08aa35c1@github.com>

> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
> 
> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
> 
> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
> 
> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

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

  Update src/java.desktop/share/classes/java/beans/beancontext/BeanContextChild.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18569/files
  - new: https://git.openjdk.org/jdk/pull/18569/files/ff50d1a8..2df2ac6e

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

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

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

From duke at openjdk.org  Wed Apr 10 18:34:16 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 10 Apr 2024 18:34:16 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext
In-Reply-To: <DXA4qkbi3Ms8vawT0VlVfeR7mNCjGmDCgy_1PY_9Mnk=.53bcce2a-dea1-43ec-8adf-ddf3f1727dde@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
 <DXA4qkbi3Ms8vawT0VlVfeR7mNCjGmDCgy_1PY_9Mnk=.53bcce2a-dea1-43ec-8adf-ddf3f1727dde@github.com>
Message-ID: <BpSeZTpPHWSGQPZ1fqoOe3uQN3zMYfExqXk-MMSZBcI=.42c25692-6499-48a1-a7ba-8abfadba8caf@github.com>

On Tue, 2 Apr 2024 15:52:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > public code corpus should be searched prior to removal in order to determine impact.
> 
> What are results of that search?

a cursory search revealed almost no usage, a more in depth search should be performed prior to actual removal.

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

PR Comment: https://git.openjdk.org/jdk/pull/18569#issuecomment-2048201162

From duke at openjdk.org  Wed Apr 10 18:34:16 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 10 Apr 2024 18:34:16 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v2]
In-Reply-To: <EwU1xX90xhszKj75pnyQjCcqiI2JQB1dXXPLLdoJIUM=.549c040d-02f1-489e-b675-da227d1dc19c@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
 <xsB-qrz5sW5_KikA0CGqjv909VezEsThw9J2gqORHPE=.b698d508-8c2a-4825-977a-7af8c69b762e@github.com>
 <EwU1xX90xhszKj75pnyQjCcqiI2JQB1dXXPLLdoJIUM=.549c040d-02f1-489e-b675-da227d1dc19c@github.com>
Message-ID: <XdxtnE8WjHzghMIF6PTQWAeGE3MbJLbD2gthKCxBCLI=.10913969-9a4f-4e05-8055-483f738e272f@github.com>

On Tue, 9 Apr 2024 13:57:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Should the copyright year be bumped to 2024 in all the modified files?

yes, my bad I'll update and push...

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

PR Comment: https://git.openjdk.org/jdk/pull/18569#issuecomment-2048202242

From duke at openjdk.org  Wed Apr 10 20:47:00 2024
From: duke at openjdk.org (Tres Finocchiaro)
Date: Wed, 10 Apr 2024 20:47:00 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS
In-Reply-To: <9NaQ7MzCph2B2CYYqk_o_yMqLtOz45sWsq8fbCk67Es=.d278e2e4-2dfe-499f-913f-b7ec47e577b9@github.com>
References: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
 <9NaQ7MzCph2B2CYYqk_o_yMqLtOz45sWsq8fbCk67Es=.d278e2e4-2dfe-499f-913f-b7ec47e577b9@github.com>
Message-ID: <mMDCiVn75G8YLqicBFdqjlcLyWzjTb4YgH7xy__-J9w=.fced4afc-2358-43b2-9edc-3fce0bf86a75@github.com>

On Mon, 8 Apr 2024 23:19:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> The fix provides ability to print Black & White pages on macOS.
>> 
>> Cocoa API has [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode) function but it is marked as deprecated and really does nothing.
>> 
>> There is no replacement; this function was included to facilitate porting legacy applications to macOS, 
>> but it serves no useful purpose.
>> 
>> Dumping `NSPrintInfo` print settings which were set by the native print dialog on macOS shows that the keys and values used for Black & White printing depend on the used printer type.
>> For example, the tested 
>> `HP Color LaserJet MFP M180n` printer uses `ColorModel` key and`Gray` value, and
>> `HP Ink Tank 110 series` uses `HPColorMode` key and `grayscale` value.
>> 
>> Printing all `NSPrintInfo` presets shows that they do not contain key/value pairs  for Black&White settings.
>> This is the code snippet used to print `NSPrintInfo` presets:
>> 
>>     PMPrinter pr;
>>     PMPrintSession printSession = (PMPrintSession)[printInfo PMPrintSession];
>>     OSStatus status = PMSessionGetCurrentPrinter(printSession, &pr);
>>     CFArrayRef presetsList = nil;
>>     status = PMPrinterCopyPresets(pr, &presetsList);
>>     CFIndex arrayCount = CFArrayGetCount(presetsList);
>> 
>>     for (CFIndex index = 0; index < arrayCount; index++) {
>>         PMPreset preset = (PMPreset)CFArrayGetValueAtIndex(presetsList, index);
>>         CFStringRef presetName = nil;
>>         if (PMPresetCopyName(preset, &presetName) == noErr && CFStringGetLength(presetName) > 0) {
>>             NSLog(@"  presetName: '%@'", presetName);
>>             NSDictionary* dict = nil;
>>             if (PMPresetGetAttributes(preset, (CFDictionaryRef*)(&dict)) == noErr) {
>>                    // print preset dict
>> 
>> 
>> The idea of the proposed fix is to store printer dependent key/value pairs in the `<jdk-home>/conf/printer.properties` property file.
>> 
>> The property file has the format:
>> 
>> print-attribute.print-attribute-value.key=value
>> 
>> where `print-attribute` is the java print attribute, `print-attribute-value` is the corresponding attribute value, and `key` and `value` is the key/value pair used by a specific printer.
>> 
>> For example, for `Chromaticity` attribute the property file could look like:
>> 
>> Chromaticity.MONOCHROME.ColorModel=Gray
>> Chromaticity.COLOR.ColorModel=CMYK
>> Chromaticity.MONOCHROME.HPColorMode=grayscale
>> Chromaticity.COLOR.HPColorMode=color
>> 
>> where `Chromaticity.MO...
>
> Since the user can always select greyscale in the user dialog, I presume you have some requirement
> to do this printing without user intervention. Perhaps there's no user there (server-side printing), or
> the app would like to make sure the user always defaults to B&W.
> 
> As far as I can tell, this isn't supported via any kind of API on macOS, so it is not a Java problem.
> You could be printing from an Objective-C app written directly to Cocoa APIs and still have the same problem.
> So a Java-specific workaround like this seems inappropriate.
> 
> I've poked around to help me understand what is going on.
> 
> When I do "Print to File" on macOS - meaning use the native printer dialog's "Save as PDF" option,
> then the generated PDF is always colour even if I select the printer dialog's "Grayscale Printing" option.
> This isn't just true for Java apps, the same happens if I print a web page from Safari.
> 
> And when I query the  Chromaticity support for a couple of colour printers - one Canon, one HP,
> both report they support it but only the value COLOR.
> 
> So I conclude the grayscale printing option is something handled by the printer driver at the time it is converted to
> the printer-specific format and sent to the physical printer and it isn't changing the rendering.
> 
> So in general without an API, to get greyscale it requires the end-user to set an option in a print dialog
> and as mentioned above, what you are trying  o enable isn't possible even if you wrote the app in
> Objective-C or Swift directly as a macOS native app.
> 
> But what works for me to get greyscale by default is to set that up as the default for the print queue.
> It is easy to add a printer twice - with two queues for it.
> One has the default set to greyscale, the other to colour. Then the app just needs to select the required queue.
> This is clearly more site-specific than having the app just specify MONOCHROME but is a lot lower cost all round.
> 
> I don't understand why PMSetColorMode is deprecated and non-functional since it seems like it would
> be the right option here, but then internally macOS would need to be able to map it to the right option.
> Doubtless that would be easier if MONOCHROME were supported by all these drivers and I don't understand
> that omission either. In fact if it were we probably could just specify that directly without macOS needing
> to understand anything - like  I expect it doesn't understand the key/value pairs your code is sending it.
> I note that you send ALL known key/value pairs and hope one ...

@prrace thanks for the detailed thoughts on this problem.  As the stakeholder in this issue, I wanted to offer some feedback to your thoughts.  I understand that the desire for OpenJDK is to NOT maintain a list of proprietary printer settings, but since many of the thoughts above get into use-case scenarios, I feel compelled to share my perspective.  I hope these are well received.

> When I do "Print to File" on macOS - meaning use the native printer dialog's "Save as PDF" option,
then the generated PDF is always colour even if I select the printer dialog's "Grayscale Printing" option.
This isn't just true for Java apps, the same happens if I print a web page from Safari.

Several PDF printers (on several OSs) ignore grayscale/b&w settings.  I'm not sure why, but I've observed the same.

> As far as I can tell, this isn't supported via any kind of API on macOS, so it is not a Java problem.
> You could be printing from an Objective-C app written directly to Cocoa APIs and still have the same problem.

Agreed.

> So a Java-specific workaround like this seems inappropriate.

As the stakeholder (biased) it's hard for me to agree, however allowing the implementing application to maintain (and thus offer) this workaround would certainly suffice.  Since AWT (quite graciously) abstracts these attributes away from the user, "wontfix" status naturally causes a feature gap, albeit not the fault of OpenJDK, but a parity that -- at a bare minimum -- could live on as -- for example -- a workaround on Stackoverflow, etc.

> But what works for me to get greyscale by default is to set that up as the default for the print queue.
> It is easy to add a printer twice - with two queues for it.

Easy is subjective (and prescriptive).  Again, biased, but setting up additional printer queues is a viable workaround, but comes at a factor of 2 queues for each color printer added to a system.  This also offers support redundancies when removing and re-adding a printer (e.g. IP, port or driver change).

> I don't understand why `PMSetColorMode` is deprecated and non-functional since it seems like it would
be the right option here, but then internally macOS would need to be able to map it to the right option.

Agreed.

>  [...] all it takes is some vendor API change or a different printer and it just won't work again.
These points and the implied maintenance cost are some of my bigger concerns with this.

Understood.

> The other idea that crossed my mind is that instead of relying on a printing solution, we could
explicitly render in greyscale. Then we could always declare MONOCHROME support and just emulate it.
But I am not sure if this is really possible - it would require changes to the rendering code and
I'm not sure if or how if we'd be able to do that properly and safely. And the risks of that clearly extend beyond printing.

Since printers can emulate grayscale using color cartridges, I do not believe this will yield the same results as expected on all printers, but I do believe this to be a creative stop-gap/workaround which may be suitable for some use-cases.  Naturally, I would expect some performance implications as a result.  As the stakeholder, I can say that this will be trickier with prints using vector graphics than those already rastered/pixels.  Speculating, vector graphics will likely be less performance-affecting, but require diving into the document modifications (e.g. PDFBOX, JavaFX) albeit more performant, will require some creative code to desaturate all color data in all objects prior to sending (or requests to add APIs thereo to each specific project).

> Perhaps there's no user there (server-side printing), or the app would like to make sure the user always defaults to B&W.

I'm not sure how much interest there is in understanding the use-case that discovered this issue, but it's part of a (pretty popular) Java app that helps print documents.  It does so through a WebSocket interface... so in that sense it is server-like (effectively headless), although it's predominantly used by ordinary, non-technical end-users and runs as a sort of background service.  Much like AWT offers a (rather) standardized API for printing, so does the Websocket interface, so "Black & White" or "Monochrome" are offered as common, selectable options.  "Always default to B&W" would be a case-by-case situation, depending on how the websocket API is offered up to the end-user.

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

PR Comment: https://git.openjdk.org/jdk/pull/18195#issuecomment-2048405524

From duke at openjdk.org  Wed Apr 10 21:25:06 2024
From: duke at openjdk.org (Larry Cable)
Date: Wed, 10 Apr 2024 21:25:06 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v4]
In-Reply-To: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
Message-ID: <BZCinBBTxYoAZj19HSYcKkMpawN0R1GZUfDpCu5nL3Y=.3cbffb2a-c5b0-4a8a-a4f0-e128dd22be0a@github.com>

> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
> 
> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
> 
> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
> 
> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**

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

  changed copyright dates, and normalized @Deprecated formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18569/files
  - new: https://git.openjdk.org/jdk/pull/18569/files/2df2ac6e..86680a2c

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

  Stats: 38 lines in 20 files changed: 1 ins; 0 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/18569.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18569/head:pull/18569

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

From serb at openjdk.org  Thu Apr 11 04:18:43 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 11 Apr 2024 04:18:43 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v4]
In-Reply-To: <BZCinBBTxYoAZj19HSYcKkMpawN0R1GZUfDpCu5nL3Y=.3cbffb2a-c5b0-4a8a-a4f0-e128dd22be0a@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
 <BZCinBBTxYoAZj19HSYcKkMpawN0R1GZUfDpCu5nL3Y=.3cbffb2a-c5b0-4a8a-a4f0-e128dd22be0a@github.com>
Message-ID: <Ak_fKS-TXdVRGIJ7S6JZc31vr55TgSyPb4u076mU0Go=.23cb14ad-7bfd-4278-8e2b-2ee4fb83d4f9@github.com>

On Wed, 10 Apr 2024 21:25:06 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
>> 
>> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
>> 
>> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
>> 
>> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed copyright dates, and normalized @Deprecated formatting

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18569#pullrequestreview-1993256591

From aivanov at openjdk.org  Thu Apr 11 09:39:03 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Apr 2024 09:39:03 GMT
Subject: RFR: 8289770: Drop IS_WINVISTA macro from ShellFolder2.cpp
Message-ID: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>

This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.

`IS_WINVISTA` was not used at all.

`IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.

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

Commit messages:
 - 8289770: Drop IS_WINVISTA macro from ShellFolder2.cpp

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

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

From pminborg at openjdk.org  Thu Apr 11 10:42:50 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 11 Apr 2024 10:42:50 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find
Message-ID: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>

While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.

This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

Commit messages:
 - Remove white space
 - Add SymbolLookup::findOrThrow

Changes: https://git.openjdk.org/jdk/pull/18474/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18474&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314592
  Stats: 93 lines in 21 files changed: 30 ins; 0 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

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

From mcimadamore at openjdk.org  Thu Apr 11 11:43:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 11:43:42 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <O5hSvRzOvRt7EDz0BAgIw5bOYFiN10jBwad19H0uc9Q=.c6021c11-0647-4375-a4f9-00aae201a67f@github.com>

On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 152:

> 150: 
> 151:     /**
> 152:      * {@return the address of the symbol with the provided {@code name} or throws an

I suggest using the same javadoc structure as the main `find` method. Note that there we have a summary, then a more detailed `@return` which talks about zero length memory segments. This should do the same.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 155:

> 153:      *          {@linkplain IllegalArgumentException} if no such address can be found}
> 154:      *<p>
> 155:      * This is a convenience method that provides better exception messages compared

I would reframe this as: "this is equivalent to the following code, but with better exception message" (for consistency with other API points in FFM where we show what a method boils down to)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1560889723
PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1560893974

From mcimadamore at openjdk.org  Thu Apr 11 11:46:40 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 Apr 2024 11:46:40 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <NjGEgqr5SEJ-IadHMjjwV24YJLxIk8h529VASlqhqkE=.0b564bc8-a088-4820-8fa2-ac13bd654445@github.com>

On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 177:

> 175:         }
> 176:         throw new IllegalArgumentException(
> 177:                 "Unable to to find a symbol with the name: " + name);

Another, more succinct, text could be "Symbol not found: <name>"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1560897671

From jwaters at openjdk.org  Thu Apr 11 12:03:40 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 11 Apr 2024 12:03:40 GMT
Subject: RFR: 8289770: Drop IS_WINVISTA macro from ShellFolder2.cpp
In-Reply-To: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
Message-ID: <84gXQJj9v93K_r27OxQS3ZwRCIdlEiqBRtA-8pCl0wk=.f2b6ed49-8519-41ca-917a-0cf81152f927@github.com>

On Thu, 11 Apr 2024 09:33:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
> 
> `IS_WINVISTA` was not used at all.
> 
> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.

Marked as reviewed by jwaters (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18736#pullrequestreview-1994012775

From ihse at openjdk.org  Thu Apr 11 13:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Apr 2024 13:59:15 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D files
Message-ID: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>

The file to build most of the java.desktop native libraries, t Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.

I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

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

Commit messages:
 - 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D files

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

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

From ihse at openjdk.org  Thu Apr 11 13:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Apr 2024 13:59:15 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D
 files
In-Reply-To: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
Message-ID: <rx3jb8B-YdpR1uML223LwHfXq5Qpwc4IVjICuBudouI=.b8d2155d-240e-4843-ad99-9e9ab6056445@github.com>

On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The file to build most of the java.desktop native libraries, t Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
> 
> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

The default github review screen makes this a bit difficult to understand, especially AwtLibraries which it sees as a diff from the old Awt2d one. I recommend viewing the new file in its entirety instead: https://github.com/openjdk/jdk/blob/8180274092fa955cb7ff002bbdf3c32053dd337e/make/modules/java.desktop/lib/AwtLibraries.gmk

Also to clarify: I have only moved the individual library compilations around, and made no other changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2049752669

From ihse at openjdk.org  Thu Apr 11 14:01:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 11 Apr 2024 14:01:41 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D
 files
In-Reply-To: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
Message-ID: <pOcNXEgzeg24RQK-JuxAGrVcKggpX_-6C-0Z_VgDz0E=.c44aac4b-2f37-4c39-917d-50939a49dd91@github.com>

On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The file to build most of the java.desktop native libraries, t Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
> 
> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

@prrace I will need your assistance in confirming that my understanding about the AWT vs 2D split is correct. In particular, `libosxui` gave me some headache, but after trying to dig into the code my understanding ended up being that this is part of Swing which is considered part of AWT, not 2D.

I also looked at `libosx` and `libosxapp` which are located in the general `Lib.gmk` file. I could not easily see that they should have been placed in either 2d or Awt, so my assumption is that they are correctly placed outside these two new files.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2049760109

From aivanov at openjdk.org  Thu Apr 11 14:49:42 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Apr 2024 14:49:42 GMT
Subject: RFR: 8321428: Deprecate for removal the package
 java.beans.beancontext [v4]
In-Reply-To: <BZCinBBTxYoAZj19HSYcKkMpawN0R1GZUfDpCu5nL3Y=.3cbffb2a-c5b0-4a8a-a4f0-e128dd22be0a@github.com>
References: <52QcdTCtLckgu3Yy6xZW-vMA8WS3gP9oTdy0sPp88F4=.c1401969-99c9-4e46-be85-f5419fe35092@github.com>
 <BZCinBBTxYoAZj19HSYcKkMpawN0R1GZUfDpCu5nL3Y=.3cbffb2a-c5b0-4a8a-a4f0-e128dd22be0a@github.com>
Message-ID: <k5mEAfl9FS4Y6S_5Ku6kaypJOZ6sT1888Swy0Zy9SKw=.00e16f8c-9acf-4ed9-bf00-dfd99acb826a@github.com>

On Wed, 10 Apr 2024 21:25:06 GMT, Larry Cable <duke at openjdk.org> wrote:

>> the beancontext package was added (by me) in JDK 1.2 to provide JavaBeans(tm) with a containment and services hierarchy.
>> 
>> based upon concepts from OpenDoc, which was a popular component model at the time, the API pre-dated the addition of language features such as annotations, and the invention and adoption of programming design patterns such as "Inversion of Control"  and/or "Dependency Injection".
>> 
>> This API (package) has not evolved with either the language or current design trends, as such it is, at best, anachronistic, and is probably an anti-pattern that should be avoided.
>> 
>> This package is therefore deprecated **FOR REMOVAL IN AT FUTURE RELEASE**
>
> Larry Cable has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed copyright dates, and normalized @Deprecated formatting

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18569#pullrequestreview-1994414574

From aivanov at openjdk.org  Thu Apr 11 16:51:41 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Apr 2024 16:51:41 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s>
In-Reply-To: <el5-1yFy-gZLBjTDYgJgYwS41s1L-j7J2SVlhZFnI7Q=.f30c428d-35d8-4c95-a64e-85267187bb6d@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <iJs-baXmf3_GrOssK-IZaVStA5fk3gJyJzV6R0DAyBM=.8eae9fd0-0f91-481e-88c1-4213f9a25287@github.com>
 <snWxj61pdQZkPPw879VA7MsORKOZTQUFU530nKjHQfQ=.6a67554b-4b09-4cdf-8a3a-9595f287a7d8@github.com>
 <el5-1yFy-gZLBjTDYgJgYwS41s1L-j7J2SVlhZFnI7Q=.f30c428d-35d8-4c95-a64e-85267187bb6d@github.com>
Message-ID: <rTvGp45JhY1GM0tptjvL61uRGXq8tdoCuUXzDN2bZE8=.4acf90e5-fa3e-4657-ad20-8dddc664cb18@github.com>

On Tue, 9 Apr 2024 20:59:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> I'm pretty sure there are other cases where `text-decoration` isn't resolved correctly. It is not a goal to resolve all of the possible issues.
>> 
>> I'll check whether this scenario can be handled easily. I don't think it is. If not, I'll submit another bug.
>
> Sounds good.

Swing does not support *multiple classes* on an HTML element.

I submitted [JDK-8330119](https://bugs.openjdk.org/browse/JDK-8330119): _No support for multiple HTML classes in Swing_. It may never be fixed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1561324559

From aivanov at openjdk.org  Thu Apr 11 17:20:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Apr 2024 17:20:12 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s> [v2]
In-Reply-To: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
Message-ID: <1F6-IlWYGmr30-PHxEFccIK73YVMm9xTUs1M34e1EWk=.d675ffc5-f514-4af5-9728-3af0450e5405@github.com>

> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
> 
> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
> 
> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
> 
> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
> 
> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
> 
> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
> 
> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
> 
> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.

Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:

 - Add 8326734 to HTMLUnderlineStrike test written for 8323801
 - Add tests for 'underline' and 'line-through'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18550/files
  - new: https://git.openjdk.org/jdk/pull/18550/files/e9cf30b3..d20f8ce8

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

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

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

From aivanov at openjdk.org  Thu Apr 11 17:25:43 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 11 Apr 2024 17:25:43 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s> [v2]
In-Reply-To: <TMZTFEY9S_o48klI0nAqKRg7tBvBJZlmpUNbn3WvrKo=.8ea84ab0-c41b-4b5c-8919-7c904a7759bd@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <rzNlwAz4Hmste23BOTQjMaaHbOdMyv3blZ43IWplRHs=.ebfad1ab-0326-468d-84b5-e647e5afdd63@github.com>
 <h3dTRyz3JUSu1ur1NOfyUZ1QnwRlo4-eH4y8JvjtAb4=.2af50d36-3485-4f53-b3d6-5233d718ce22@github.com>
 <TMZTFEY9S_o48klI0nAqKRg7tBvBJZlmpUNbn3WvrKo=.8ea84ab0-c41b-4b5c-8919-7c904a7759bd@github.com>
Message-ID: <Px6Jo9Y-0GOlvy_nQxCf-RIe2w0dzuj-29LqSTX76wM=.4bec50d2-0e42-4cc6-b648-f9b2e5359391@github.com>

On Tue, 9 Apr 2024 20:24:06 GMT, Phil Race <prr at openjdk.org> wrote:

>> Because you didn't add the backticks <code>`</code> around your sample, it's interpreted as HTML, and I can't really see it.
>> 
>> I guess, the code was something line this: `<span style='text-decoration: line-through'><s>`.
>> 
>> If the both tags have the same value for the `text-decoration` property, it works without the fix. I'm sure it works with the fix, however, in some cases the value of the property may be `line-through,line-through`.
>> 
>> I'll add another test if you think such a scenario is worth verifying too.
>
> I added the backticks so it now shows the source but all I did was `"s/<u>/<s>/"`
> 
> Yes, I think it might be wise to add such a test scenario.

Added `HTMLUnderlineOnly.java` and `HTMLStrikeOnly.java` which test different combinations of setting `underline`  and `line-through` values for the `text-decoration` CSS property.

These two tests pass with and **without** the fix. This means neither is a regression test for [JDK-8326734](https://bugs.openjdk.org/browse/JDK-8326734). Shall I remove `8326734` from `@bug` tag from the tests?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18550#discussion_r1561360248

From jjg at openjdk.org  Thu Apr 11 20:55:24 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 11 Apr 2024 20:55:24 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <au6_FZORG1xVh5VnfoMMR60a_2oa1qny0ElKeIGpvFI=.94ed31a5-a875-4bc6-927b-da0f512ad43e@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  adjust call for `saveDanglingDocComments` for enum members

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3d6f1f95..56d6dcac

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

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

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

From honkar at openjdk.org  Fri Apr 12 00:18:42 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 12 Apr 2024 00:18:42 GMT
Subject: RFR: 8326734: text-decoration applied to <span> lost when mixed
 with <u> or <s> [v2]
In-Reply-To: <1F6-IlWYGmr30-PHxEFccIK73YVMm9xTUs1M34e1EWk=.d675ffc5-f514-4af5-9728-3af0450e5405@github.com>
References: <nfmH-qI_aIzq9SPeqbbomIDAczMRWiAtrDYLB7Km3s4=.27bf7f8b-1d81-4965-ac1e-e29b1b8843fd@github.com>
 <1F6-IlWYGmr30-PHxEFccIK73YVMm9xTUs1M34e1EWk=.d675ffc5-f514-4af5-9728-3af0450e5405@github.com>
Message-ID: <0w0wOMEpTHdjxLGdty41CiB3T2skF5nYvhv_TfkNiFg=.cc71698c-94a6-4744-bc7a-7a35b0034f62@github.com>

On Thu, 11 Apr 2024 17:20:12 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The value of the [`text-decoration`](https://www.w3.org/TR/REC-CSS1/#text-decoration) CSS property is not inherited correctly in Swing. If the `<span>` element is mixed with `<u>` or `<s>`, only the value from the `style` attribute of `<span>` is applied.
>> 
>> The fix to this issue is not as simple as that for the previous one in PR #17659, [JDK-8323801](https://bugs.openjdk.org/browse/JDK-8323801). Even in the seemingly simple case where `<u>` is followed by `<span style='text-decoration: line-through'>`, the situation is more complex because the styles are stored in `MuxingAttributeSet` in different elements of the array.
>> 
>> To resolve this problem, `CSS.Attribute.TEXT_DECORATION` is treated as a special case. Indeed, it is a special case: the values set to a single `text-decoration` property should be combined across the entire tree of nested HTML elements and their styles.
>> 
>> So, `MuxingAttributeSet` looks for `text-decoration` in the entire array and combines all the values.
>> 
>> The same way, `StyleSheet` also goes up the inheritance chain by combining the current value of `text-decoration` with that from `getResolveParent`.
>> 
>> The `ConvertSpanAction` combines the value of `text-decoration` of adjacent `<span>` elements.
>> 
>> Finally, `ConvertAction` and `CharacterAction` are refactored. The `ConvertAction` class duplicated the code from `CharacterAction`. Now `ConvertAction` extends `CharacterAction` and overrides a method to provide additional handling.
>> 
>> Thus, [JDK-8325620](https://bugs.openjdk.org/browse/JDK-8325620) is also resolved by this PR, the action used for `<b>`, `<i>`, `<u>` is `CharacterAction` as specified.
>
> Alexey Ivanov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add 8326734 to HTMLUnderlineStrike test written for 8323801
>  - Add tests for 'underline' and 'line-through'

Text-decoration changes looks good to me.
Although there are some outlier cases ([JDK-8330119](https://bugs.openjdk.org/browse/JDK-8330119)) they are not directly related to the current fix and the combinations tested in HTMLTextDecoration are comprehensive and covers the required use cases.

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18550#pullrequestreview-1995663800

From tr at openjdk.org  Fri Apr 12 04:06:09 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Apr 2024 04:06:09 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v4]
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <8C3O4zbsoRQaMlQ5t5ocBJguUmDKc4Fau9P2ps25bAI=.b86df9ec-2233-4eca-a4cb-b062e87343ec@github.com>

> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.

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

  Review updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18187/files
  - new: https://git.openjdk.org/jdk/pull/18187/files/3dfb3120..ebd42ae0

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

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

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

From rkannathpari at openjdk.org  Fri Apr 12 04:32:40 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 12 Apr 2024 04:32:40 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
 <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
Message-ID: <Lb5phv_mC3JPbOUJx_ZICMZnwG-JhQyXyNwlwP5Mzrw=.2b4472c3-53b5-4b35-aeca-697c76211eba@github.com>

On Mon, 8 Apr 2024 07:57:11 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
>> 
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated insturction style
>  - Updated suggesions

Yes this will work on Print to pdf, I don't think physical printer is must.

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

PR Comment: https://git.openjdk.org/jdk/pull/18624#issuecomment-2050953129

From tr at openjdk.org  Fri Apr 12 05:01:42 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Apr 2024 05:01:42 GMT
Subject: RFR: 8289770: Drop IS_WINVISTA macro from ShellFolder2.cpp
In-Reply-To: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
Message-ID: <zp6Qu5h31QHKuKoo6HtL_2Z7OpNI1CyoYpgPAhzg1hw=.c824fe00-f633-4f0f-ac02-f6be4791fc4e@github.com>

On Thu, 11 Apr 2024 09:33:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
> 
> `IS_WINVISTA` was not used at all.
> 
> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.

Can you update JBS title and description regarding "support for icons with alpha channel" too. These updates are visible only in PR and not in JBS.

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

PR Review: https://git.openjdk.org/jdk/pull/18736#pullrequestreview-1995873453

From abhiscxk at openjdk.org  Fri Apr 12 05:07:43 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Apr 2024 05:07:43 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <Lb5phv_mC3JPbOUJx_ZICMZnwG-JhQyXyNwlwP5Mzrw=.2b4472c3-53b5-4b35-aeca-697c76211eba@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
 <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
 <Lb5phv_mC3JPbOUJx_ZICMZnwG-JhQyXyNwlwP5Mzrw=.2b4472c3-53b5-4b35-aeca-697c76211eba@github.com>
Message-ID: <e6_00nCqrZoevyPnuvZOjQCFRBvWeZe2iW9pheVRYjY=.ed429003-7bc6-4f08-978e-fec6ea9e9571@github.com>

On Fri, 12 Apr 2024 04:30:34 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Yes this will work on Print to pdf, I don't think physical printer is must.

I am getting this dialog message "Printer status is not available at this time."

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

PR Comment: https://git.openjdk.org/jdk/pull/18624#issuecomment-2050982752

From rkannathpari at openjdk.org  Fri Apr 12 05:18:43 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 12 Apr 2024 05:18:43 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
 <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
Message-ID: <zVMkN8ZWVx1FHkXcUvMYg0SP5K6x1FAlJihHMdNUrbs=.d0baec00-697d-4ebc-82f7-92a961659f14@github.com>

On Mon, 8 Apr 2024 07:57:11 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
>> 
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated insturction style
>  - Updated suggesions

Its working for me, please make sure you have configured pdf printer as your default printer. In this test there is no option to select printer.

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

PR Comment: https://git.openjdk.org/jdk/pull/18624#issuecomment-2050993229

From abhiscxk at openjdk.org  Fri Apr 12 05:36:43 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Apr 2024 05:36:43 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <zVMkN8ZWVx1FHkXcUvMYg0SP5K6x1FAlJihHMdNUrbs=.d0baec00-697d-4ebc-82f7-92a961659f14@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
 <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
 <zVMkN8ZWVx1FHkXcUvMYg0SP5K6x1FAlJihHMdNUrbs=.d0baec00-697d-4ebc-82f7-92a961659f14@github.com>
Message-ID: <qNE6oC-q1gkRJ1N70lg76SdRLItP8iZlocpEDNNW6Uk=.45dc0d65-ae20-4db1-8ef1-9374451c43ad@github.com>

On Fri, 12 Apr 2024 05:15:53 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Its working for me, please make sure you have configured pdf printer as your default printer. In this test there is no option to select printer.

Yeah... default was set to physical printer which is currently inaccessible. Working fine for me also.

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

PR Comment: https://git.openjdk.org/jdk/pull/18624#issuecomment-2051010834

From abhiscxk at openjdk.org  Fri Apr 12 05:49:41 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Apr 2024 05:49:41 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
 <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
Message-ID: <QkAMx7WpgT0Ni86Qk9ZjczFvYe_60VO72krh4wGhqVo=.37e39c22-715c-44d2-9e0f-912de091d30c@github.com>

On Mon, 8 Apr 2024 07:57:11 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
>> 
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated insturction style
>  - Updated suggesions

LGTM.

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

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18624#pullrequestreview-1995915597

From abhiscxk at openjdk.org  Fri Apr 12 05:58:42 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 12 Apr 2024 05:58:42 GMT
Subject: RFR: 8322140: javax/swing/JTable/JTableScrollPrintTest.java does
 not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel [v4]
In-Reply-To: <8C3O4zbsoRQaMlQ5t5ocBJguUmDKc4Fau9P2ps25bAI=.b86df9ec-2233-4eca-a4cb-b062e87343ec@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
 <8C3O4zbsoRQaMlQ5t5ocBJguUmDKc4Fau9P2ps25bAI=.b86df9ec-2233-4eca-a4cb-b062e87343ec@github.com>
Message-ID: <8lgcga5Q3XcDK0eo5VHL7FSCLELSxYL8TsRokJ_xHTk=.6360f751-4d35-46f7-9678-db461206e0cb@github.com>

On Fri, 12 Apr 2024 04:06:09 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review updates

Looks good to me now.

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

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18187#pullrequestreview-1995924035

From tr at openjdk.org  Fri Apr 12 10:24:47 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 12 Apr 2024 10:24:47 GMT
Subject: Integrated: 8322140: javax/swing/JTable/JTableScrollPrintTest.java
 does not print the rows and columns of the table in Nimbus and Aqua
 LookAndFeel
In-Reply-To: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
References: <YUFppwxpjJjubF-XhqDDe1xcdIes9ErKzA563fjF0oY=.2e79d2c5-f743-49b0-be82-27dd4c4403bd@github.com>
Message-ID: <etnp9IUcZSYssLTg9vgMaQ_PviAZy6AmV4A9lpiSwZc=.10d8deb1-ca24-4537-8b88-e8e3b2ef893b@github.com>

On Mon, 11 Mar 2024 10:05:41 GMT, Tejesh R <tr at openjdk.org> wrote:

> Fix suggested in bug [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) had a regression in Nimbus L&F yet it resolved the issue in other L&F. The better approach would be to handle `MultiResolutionImages `in `PathGraphics` class `getBufferedImage` method and is suggested here. The fix doesn't cause any regression and is verified in CI system. The test javax/swing/JTable/JTableScrollPrintTest.java is verified for all platforms and all L&F (Except in Windows it doesn't work due an issue ([JDK-8322135](https://bugs.openjdk.org/browse/JDK-8322135)) introduced in 22, yet to investigate on it). And also fix [8210807](https://github.com/openjdk/jdk/commit/38bbbe7588c94d3a0edd1c120ba49cbd0851a720) has been reverted, retaining the test.

This pull request has now been integrated.

Changeset: 717a07b9
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/717a07b932e3dcabbad130d299b15cb963d50a67
Stats:     62 lines in 4 files changed: 26 ins; 19 del; 17 mod

8322140: javax/swing/JTable/JTableScrollPrintTest.java does not print the rows and columns of the table in Nimbus and Aqua LookAndFeel

Reviewed-by: psadhukhan, abhiscxk

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

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

From jjg at openjdk.org  Fri Apr 12 17:24:43 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 17:24:43 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v2]
In-Reply-To: <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <CJk_cgw_oK69SgmEsA7fC7wupoZ6Uc_MJ_vAEFUhMlc=.3b61473c-97e6-4a9a-b19b-e387ab9eb5ab@github.com>
Message-ID: <yoXk0XJ1mo_6lFPzenTjynOJmM2R8GNROFOTwN4p00g=.dcedceac-6d2a-4b1f-99ee-57d060b8a69b@github.com>

On Wed, 3 Apr 2024 10:01:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   adjust call for `saveDanglingDocComments` for enum members
>
> The build changes look okay. 
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

@magicus 
> The build changes look okay.
> 
> Do you have any plan of going through all the Java modules and fixing the issues, or opening JBS issues to have them fixed? Or will these lint warnings remain disabled for the foreseeable future?

The plan is to create an umbrella bug to clean up the individual modules. There is interest to clean up `java.base`, to keep that one free of any warnings, and I can see that the lang tools modules will get cleaner up as well. It will be up to other component teams to decide if and when to clean up other parts of the system.  Once this work has been integrated, it is relatively easy to enable the warnings for a module and to fix the ensuing issues. Since any changes "only" involve comments, it should be reasonably easy to fix them, unlike some pervasive other warnings, like `this-escape`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18527#issuecomment-2052174696

From aivanov at openjdk.org  Fri Apr 12 19:11:45 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 12 Apr 2024 19:11:45 GMT
Subject: RFR: 8289770: Remove Windows version macro from ShellFolder2.cpp
In-Reply-To: <zp6Qu5h31QHKuKoo6HtL_2Z7OpNI1CyoYpgPAhzg1hw=.c824fe00-f633-4f0f-ac02-f6be4791fc4e@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
 <zp6Qu5h31QHKuKoo6HtL_2Z7OpNI1CyoYpgPAhzg1hw=.c824fe00-f633-4f0f-ac02-f6be4791fc4e@github.com>
Message-ID: <cp8CXFJVhFCxrd0l2pUtqmG6OCykq9Sv-jiZSvNk4x8=.510ba9d1-41a8-49fe-9c14-b345aeee9d7d@github.com>

On Fri, 12 Apr 2024 04:59:17 GMT, Tejesh R <tr at openjdk.org> wrote:

> Can you update JBS title and description regarding "support for icons with alpha channel" too. These updates are visible only in PR and not in JBS.

Updated the JBS subject.

Added [a comment](https://bugs.openjdk.org/browse/JDK-8289770?focusedId=14664984&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14664984) with break-up of macro usages.

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

PR Comment: https://git.openjdk.org/jdk/pull/18736#issuecomment-2052368353

From jjg at openjdk.org  Fri Apr 12 21:04:06 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 12 Apr 2024 21:04:06 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v3]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <3Ynu_D2CcFh3usjCkWQVk7VFhTlxVzD4f2nVhvZrP50=.f1c29740-ff73-4a0c-a63b-3e00ece05bbf@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  call `saveDanglingDocComments` for local variable declarations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/56d6dcac..3f745431

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

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

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

From prr at openjdk.org  Fri Apr 12 22:47:51 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 12 Apr 2024 22:47:51 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D
 files
In-Reply-To: <pOcNXEgzeg24RQK-JuxAGrVcKggpX_-6C-0Z_VgDz0E=.c44aac4b-2f37-4c39-917d-50939a49dd91@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <pOcNXEgzeg24RQK-JuxAGrVcKggpX_-6C-0Z_VgDz0E=.c44aac4b-2f37-4c39-917d-50939a49dd91@github.com>
Message-ID: <Xlhwr9ECrwRBQIbnR-Jp5hxKzjxeWfWZSGoSvqjzS0k=.79063cdc-4c7f-40d8-a71c-042b0f84380d@github.com>

On Thu, 11 Apr 2024 13:59:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> @prrace I will need your assistance in confirming that my understanding about the AWT vs 2D split is correct. In particular, `libosxui` gave me some headache, but after trying to dig into the code my understanding ended up being that this is part of Swing which is considered part of AWT, not 2D.
> 
> I also looked at `libosx` and `libosxapp` which are located in the general `Lib.gmk` file. I could not easily see that they should have been placed in either 2d or Awt, so my assumption is that they are correctly placed outside these two new files.

Swing isn't part of AWT. They are separate entities.
Swing is built on top of 2D as much as it is built on top of AWT.

Any hope of finding a neat dividing line will be arbitrary and not really reflecting reality

And in some ways AWT is more closely tied to AWT than 2D is.

And things are not the same across platforms either.
You've determined splashscreen is 2D functionality which it most certainly is not.

Awtlibraries is setting up the shaders which for the Metal rendering pipeline which is 100% 2D.

And it seems to be building OpenGL, etc as well ..

and generally I see so manay references to 2D in the AWT file and vice versa.

it isn't even true that "libawt" is awt. Libawt  is mostly a misnomer, in one case more than mostly. It ought to be called "lib2d"

So I think this change will just cause confusion and doesn't seem right to me. It ought to "not happen".

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2052648551

From prr at openjdk.org  Sat Apr 13 18:16:43 2024
From: prr at openjdk.org (Phil Race)
Date: Sat, 13 Apr 2024 18:16:43 GMT
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
 [v2]
In-Reply-To: <L83q9-jn2-qpuV2Cto24B80SWaq-qB0lnzSKY_5lUcg=.453ac025-217a-42d1-b0cd-64eb55524cf6@github.com>
References: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
 <L83q9-jn2-qpuV2Cto24B80SWaq-qB0lnzSKY_5lUcg=.453ac025-217a-42d1-b0cd-64eb55524cf6@github.com>
Message-ID: <w83ARZFG9gLT9bgB-WrwYUJBWPZz4Gfa1jnQYUP0x68=.ca285748-4dad-4a6b-a61d-b08984daf165@github.com>

On Sat, 11 Nov 2023 12:32:15 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.
>
> Jan Trukenm?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduced line lengths

This all sounds good to me but @mrserb should approve too since he was looking at it.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16546#pullrequestreview-1999326830

From prr at openjdk.org  Sat Apr 13 18:24:44 2024
From: prr at openjdk.org (Phil Race)
Date: Sat, 13 Apr 2024 18:24:44 GMT
Subject: RFR: 8233177: Remove testcase for JDK-8001470 as fix has been
 reverted [v3]
In-Reply-To: <uh91qg03N0Cko_uz7PzVSv_4XC9hn5fUFnK-EByMAvE=.488b0c91-df8a-4f04-b202-09ff3023cbdc@github.com>
References: <WdiPVxEBxj-EamGyS3N6BDJti2_2_OiQSw_SHAUbeo4=.deb56df4-3c99-412e-b2e1-740f73ff9b3f@github.com>
 <uh91qg03N0Cko_uz7PzVSv_4XC9hn5fUFnK-EByMAvE=.488b0c91-df8a-4f04-b202-09ff3023cbdc@github.com>
Message-ID: <ONjTFu58n20lXsCfeXH45obu-EKE9kr3LM4euI3d-dU=.ab2199b0-adff-4365-b676-adce6f4375c6@github.com>

On Tue, 13 Feb 2024 07:50:15 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Existing regression test is failing because textfield height is not as per test's expectation..Seems like the indic character being tried to render is not being loaded (probably because of missing glyphs) leading to 0 preferredSpan from [BoxView](https://github.com/openjdk/jdk/blame/5a74c2a67ebcb47e51732f03c4be694bdf920469/src/java.desktop/share/classes/javax/swing/text/BoxView.java#L545-L552) which is superclass for `i18nFieldVIew`, the field view for Indic characters.
>> Tried block character in the test which is now being loaded properly leading to correct height..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test removed as corresponding fix is reverted

Where are we with this ? Is there a consensus yet ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17528#issuecomment-2053723368

From prr at openjdk.org  Sun Apr 14 00:53:53 2024
From: prr at openjdk.org (Phil Race)
Date: Sun, 14 Apr 2024 00:53:53 GMT
Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute
 extension [v5]
In-Reply-To: <1IZMIOuXSec2PYnGvp5rTDBFDatCsAh1lcZOhwTR2oM=.058bb44a-b228-41af-99fc-de0f602370fb@github.com>
References: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
 <1IZMIOuXSec2PYnGvp5rTDBFDatCsAh1lcZOhwTR2oM=.058bb44a-b228-41af-99fc-de0f602370fb@github.com>
Message-ID: <CP4KsiCXTNlbqlfArESEchdHY0dWfzJgMJHXSsbRtHk=.3e3d6757-5120-4c19-8bca-130c8d01620e@github.com>

On Wed, 13 Dec 2023 15:58:03 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

>> The fix adds new public `OutputBin` print attribute class which allow to set a printer output bin in a `PrinterJob` class. The corresponding internal `CustomOutputBin` class is added as well.
>> 
>> - Constants used in `OutputBin` class are based on [Internet Printing Protocol (IPP): ?output-bin? attribute extension](https://ftp.pwg.org/pub/pwg/candidates/cs-ippoutputbin10-20010207-5100.2.pdf) document.
>> - `CUPSPrinter.getOutputBins(String printer)` method uses PPD  `ppdFindOption(..., "OutputBin")` function to get supported output bins for the given printer on native level.
>> - The fix propagates the `OutputBin` attribute from the printer job attributes to `NSPrintInfo` print settings with `OutputBin` key on macOS.
>> 
>> The fix was tested on `Kyocera ECOSYS M8130cidn` printer where `ppdFindOption(..., "OutputBin")` call returns 4 output bins (text, choice): 
>> - Printer settings, None
>> - Inner tray, INNERTRAY
>> - Separator tray, SEPARATORTRAY
>> - Finisher (face-down), Main
>> 
>> if `Printer settings`, `Inner tray`, or `Finisher (face-down)` CustomOutputBins is set to `PrinterJob.print(...)` attributes a test page is printed to the Main tray of the  `Kyocera ECOSYS M8130cidn` printer. If `Separator tray` is used a page is printed to the Separator tray. This is consistent with the printer behavior when a native print dialog is used from a native Preview app to print a document on macOS.
>
> Alexander Scherbatiy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add output bins support to the common print dialog

src/java.desktop/share/classes/javax/print/attribute/standard/OutputBin.java line 53:

> 51:  * attribute value.
> 52:  */
> 53: public class OutputBin extends EnumSyntax

Do we see a reason for applications to subclass OutputBin ?
If not perhaps it could be a sealed class.
Of course given that this isn't the case for all the other attributes it probably doesn't add much.

src/java.desktop/share/classes/javax/print/attribute/standard/OutputBin.java line 55:

> 53: public class OutputBin extends EnumSyntax
> 54:         implements DocAttribute, PrintRequestAttribute, PrintJobAttribute {
> 55: 

Not sure I see this as a DocAttribute. We have a couple of dubious DocAttributes, but I don't see the bin the output is sent to as a property of the document.

Also this class needs to be added to the table here :
https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/print/attribute/standard/package-summary.html

src/java.desktop/share/classes/javax/print/attribute/standard/OutputBin.java line 57:

> 55: 
> 56:     /**
> 57:      * Use serialVersionUID from JDK 1.4 for interoperability.

Obviously not the case here. I think you should just delete this comment.

src/java.desktop/share/classes/sun/print/CustomOutputBin.java line 60:

> 58:      */
> 59:     public static CustomOutputBin createOutputBin(String name, String choice) {
> 60:         for(CustomOutputBin bin: customEnumTable) {

for( -> for (

and perhaps this method should be synchronized.

BTW I assume this loop is meant to be equivalent to what you did here https://github.com/openjdk/jdk/pull/16167/files ?


Not sure where else to put this question but in the PR description you wrote
The fix was tested on Kyocera ECOSYS M8130cidn printer where ppdFindOption(..., "OutputBin") call returns 4 output bins (text, choice):

Printer settings, None
Inner tray, INNERTRAY
Separator tray, SEPARATORTRAY
Finisher (face-down), Main
And (eg)
If Separator tray is used a page is printed to the Separator tray.

I would have assumed "SEPARATORTRAY" was the keyword name you would specify to the job and "Separator Tray" is just a description - which could be used in a UI menu.
Am I missing something ?

src/java.desktop/share/classes/sun/print/CustomOutputBin.java line 69:

> 67: 
> 68:     /**
> 69:      * Use serialVersionUID from JDK 1.4 for interoperability.

delete comment

src/java.desktop/share/classes/sun/print/ServiceDialog.java line 1333:

> 1331: 
> 1332:         private MediaPanel pnlMedia;
> 1333:         private OutputPanel pnlOutput;

I've mulled this over and I'm not sure that Page Setup is where this should appear. I suspect you considered it analogous to  Source but IPP considers input tray to be a Media.

I don't think everything is logical about the rest of how things are divided up/named either but I just don't see it as a Page Setup option.

I think it might be better placed under Sides + Job Attributes on the so-called "Appearance" tab.

src/java.desktop/share/classes/sun/print/resources/serviceui.properties line 32:

> 30: border.jobattributes=Job Attributes
> 31: border.media=Media
> 32: border.output=Output

You only updated the default file.
You MUST update all of them, even if you just use English as above. If you don't do this and you are in (say) Germany with language set to German then the dialog will fail like this

Exception in thread "AWT-EventQueue-0" java.lang.Error: Fatal: Resource for ServiceUI is broken; there is no border.output key in resource

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1564267144
PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1564264748
PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1564262491
PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1564267453
PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1564269482
PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1564302988
PR Review Comment: https://git.openjdk.org/jdk/pull/16166#discussion_r1564296838

From prr at openjdk.org  Sun Apr 14 00:59:49 2024
From: prr at openjdk.org (Phil Race)
Date: Sun, 14 Apr 2024 00:59:49 GMT
Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute
 extension [v3]
In-Reply-To: <JHcXVoVcjOODPvBoEtKWgPaA4ChHeD3cmgDPKSdU1Ro=.d0f441a6-41ae-48a7-a81a-ce0650c3ebd5@github.com>
References: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
 <YMk-iyHrx0htxEQwqlu3mLi6Rw1wNfADcPr11gQ4tw0=.d4fd6f5a-f98d-46cf-be54-fc0268586df3@github.com>
 <JHcXVoVcjOODPvBoEtKWgPaA4ChHeD3cmgDPKSdU1Ro=.d0f441a6-41ae-48a7-a81a-ce0650c3ebd5@github.com>
Message-ID: <L07x3XJS1ErYfI9HSjeiWmJwCQ2IHlqeExXpQh7xFKk=.7b690aa2-f081-47fe-a639-a27918c0a516@github.com>

On Thu, 7 Dec 2023 12:34:13 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> One more question which I have relates to the java common print dialog. It needs to contain list of available output bins. Is it safe to assume that the first output bin retrieved by `ppdFindOption(ppd, "OutputBin")` is the default one? Or should there be added one more `Default` option for the default output bin selection?

You should definitely query for the default.  But then how to use it ..

The way the dialog works is that there's an initial set of attributes (needed if the user cancels)
and the "asCurrent" which starts out as a copy of that inital set.
Anything not in the initial set, or if the default value is not supported, we look for the default value - assuming
that the category is supported at all -  and that's what is the selected item in the dialog UI but that does
NOT cause the default to be copied to asCurrent.
So if the user selects a different printer, the dialog gets the new printer's default - if any is supported.
The general idea being anything they didn't touch should mean "use the default".

But if the user explicitly selects a value it is added to asCurrent and carried over to the next printer, so long
as it is a supported value there, otherwise its discarded (at least that's the intended idea).
So if you don't know the default, it isn't very easy to do the right thing.

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

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

From abhiscxk at openjdk.org  Mon Apr 15 07:27:42 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 15 Apr 2024 07:27:42 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <8qq6nbU7OBNV1_bU9UAt2Rha4vEK4096wpPzhKSXwZQ=.cc8ab8d6-0aaa-4437-9cbe-b244deac7f79@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

Looks good to me.

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

Marked as reviewed by abhiscxk (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18706#pullrequestreview-2000200190

From ihse at openjdk.org  Mon Apr 15 07:56:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 07:56:44 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D
 files
In-Reply-To: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
Message-ID: <YABOQc2h1hHShNCdh8eD08LSCuks5qfzxZYy22Jq7pY=.18d0d7e5-c01f-42d0-b832-6c1e2181a137@github.com>

On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
> 
> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

But the current solution is no good, either. For instance, the ordering is strange. awt_xawt and awt_lwawt is placed in opposite ends of the file, even though they are in some sense just platform specific variants of the same thing. And the entire file is huge and hard to navigate.

> and generally I see so manay references to 2D in the AWT file and vice versa.
> it isn't even true that "libawt" is awt. Libawt is mostly a misnomer, in one case more than mostly. It ought to be called "lib2d"

If this is the case, then it is clearly hopeless to try and split up the native code based on which area the source code used to compile it came from.

So let's go back to another approach: My starting point for this split was to take everything with "awt" in the name, and move it to a separate file. (I naively assumed that libs named "awt" belonged to AWT.) After reviewing the other libraries, my conclusion was to move yet another library there. But let's get that away from there.

So what if we keep the libraries named "awt" in a separate file, and all other in another file -- mostly this separation, but we agree that the reason for separation is not due to source code provenance, but just the name of the resulting libraries, and it does not need to signify anything but a need to be able to navigate in complex make files. And let's rename the "2dLibraries.gmk" file to `ClientLibraries.gmk` instead, so it is clear that there is no pretending that this is supposed to represent a 2D/AWT split.

Would that sound okay to you?

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2055999383

From pminborg at openjdk.org  Mon Apr 15 08:37:55 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 08:37:55 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v2]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <PnQQ1SSVPLCXgkF0ibFC6zS_4whAKNo5w3vf0CxsZ7g=.14452427-ceff-49c6-9327-7687e7594515@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Fix typo
 - Update after PR comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/159b9c44..7de90243

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

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

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

From jdv at openjdk.org  Mon Apr 15 08:46:46 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 15 Apr 2024 08:46:46 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>
Message-ID: <l3zam1cF7w16aPAu6ZeT_ERZM-86lRZV4a07We9sSGI=.5282f101-62b8-47d0-8062-822ae75ff004@github.com>

On Fri, 5 Apr 2024 19:47:23 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 40:

> 38: import static java.awt.image.BufferedImage.TYPE_INT_ARGB;
> 39: 
> 40: /*

Usually we keep jtreg comment section before imports.

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 58:

> 56: 
> 57:     private static void createCombo() {
> 58:         combo = new JComboBox();

If we can use unicode blank character instead of "Simple JComboBox" text. I think we make this test more robust and avoid tolerance checks.

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 101:

> 99:         ImageIO.write(enabledImage2, "png", new File(testDir
> 100:                 + "/" + lafName + "EnabledDLCR.png"));
> 101:         ImageIO.write(disabledImage2, "png", new File(testDir

We are saving these images even in the case where test passes. In my local macOS run i see 16 images getting saved in JTwork folder. This will end up taking good amount of space in our CI test systems.

We should save image only in case of test failure foe debugging purpose.

Also i see images with `Mac OS X***.png` filename and all of them are just blank and there is no combobox. Is that fine?

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 125:

> 123:                 dColor2 = new Color(disabledImage2.getRGB(x + 1, y - 1));
> 124:             } else if (lafName.equals("GTK+")) {
> 125:                 // In GTK LAF, the ComboBox sizes are different and

Is there any way to get these internal offsets programmatically and not use constants?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1565382137
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1565390546
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1565387866
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1565393803

From tr at openjdk.org  Mon Apr 15 09:34:44 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 15 Apr 2024 09:34:44 GMT
Subject: RFR: 8289770: Remove Windows version macro from ShellFolder2.cpp
In-Reply-To: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
Message-ID: <2bFh2gcoz-uOVpNNfq8fofkWf7DEoWxg1nyhC3Awlf0=.92865891-cd64-4959-bfda-b0157431ac6e@github.com>

On Thu, 11 Apr 2024 09:33:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
> 
> `IS_WINVISTA` was not used at all.
> 
> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.

Marked as reviewed by tr (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18736#pullrequestreview-2000533672

From mcimadamore at openjdk.org  Mon Apr 15 09:44:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 09:44:42 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v2]
In-Reply-To: <PnQQ1SSVPLCXgkF0ibFC6zS_4whAKNo5w3vf0CxsZ7g=.14452427-ceff-49c6-9327-7687e7594515@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <PnQQ1SSVPLCXgkF0ibFC6zS_4whAKNo5w3vf0CxsZ7g=.14452427-ceff-49c6-9327-7687e7594515@github.com>
Message-ID: <en2p_TxXXhpIpL1UoVnKaahC_ciqD6FxkrAXvYJn2Z4=.f7daf05a-ce73-4106-b22b-d15992e4101a@github.com>

On Mon, 15 Apr 2024 08:37:55 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix typo
>  - Update after PR comments

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 154:

> 152:      * Returns the address of the symbol with the given name or throws an Exception.
> 153:      *<p>
> 154:      * This is equivalent to the following code, but is more resource efficient:

Suggestion:

     * This is equivalent to the following code, but is more efficient:

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1565485693

From ihse at openjdk.org  Mon Apr 15 11:37:40 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 11:37:40 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D
 files
In-Reply-To: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
Message-ID: <HPvS2owi7BRk6VTDw-u5nPKh9fentINVoIJE8jltM3Q=.80707783-447d-4ff8-8032-4e9900d295cb@github.com>

On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
> 
> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

To rephrase myself: The goal here is to bring a huge Makefile into manageable chunks. I thought this could be done by separating AWT and 2D, but if that is not possible then any kind of predictable split is fine. I could just as well order libraries alphabetically by name and split the file half way down.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2056613043

From ihse at openjdk.org  Mon Apr 15 12:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 12:01:49 GMT
Subject: RFR: 8325163: Enable -Wpedantic on clang [v2]
In-Reply-To: <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
 <qja7u1WGpMGYvymUwKDAfovke8Kplizcby_j0hNN-r4=.9a3603e4-1446-4b57-9059-7553d21c64a1@github.com>
Message-ID: <x59-5FRsoG8BgigMF9cO8pdIPeevWfwdq8ejSxnvRSg=.798655fc-6685-4a4c-b460-46f0b5da5ab2@github.com>

On Mon, 5 Feb 2024 10:58:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
>> 
>> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
>> 
>> 
>> #define DEBUG_ONLY(code) code;
>> 
>> DEBUG_ONLY(foo());
>> 
>> 
>> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   FIx dtrace build

I'll close this now. I guess if we want to make progress on this, we will probably have to evaluate every individual warning separately, and add those which does make sense (e.g. `import-preprocessor-directive-pedantic`), and ignore the rest. I personally will not have time nor interest in driving this forward, at least not right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17687#issuecomment-2056659089

From ihse at openjdk.org  Mon Apr 15 12:01:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 15 Apr 2024 12:01:49 GMT
Subject: Withdrawn: 8325163: Enable -Wpedantic on clang
In-Reply-To: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
References: <vXYByM6yWkaXbcmeoVEFhax5Ttw-oWqcckV8kFGnKug=.ea49e50a-7734-43af-84a9-f89652fc71f6@github.com>
Message-ID: <rrtpUalai1V2FJAlnUszRYP6DiX3YbrT93jC2_hGk_I=.78d8446b-dbba-4e11-8bb7-b7b6fa326c14@github.com>

On Fri, 2 Feb 2024 15:22:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Inspired by (the later backed-out) [JDK-8296115](https://bugs.openjdk.org/browse/JDK-8296115), I propose to enable `-Wpedantic` for clang. This has already found some irregularities in the code, like mistakenly using `#import` instead of `#include`. In this patch, I disable warnings for these individual buggy or badly written files, but I intend to post follow-up issues on the respective teams to have them properly fixed.
> 
> Unfortunately, it is not possible to enable `-Wpedantic` on gcc, since individual warnings in `-Wpedantic` cannot be disabled. This means that code like this:
> 
> 
> #define DEBUG_ONLY(code) code;
> 
> DEBUG_ONLY(foo());
> 
> 
> will result in a `; ;`. This breaks the C standard, but is benign, and we use it all over the place. On clang, we can ignore this by `-Wno-extra-semi`, but this is not available on gcc.

This pull request has been closed without being integrated.

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

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

From pminborg at openjdk.org  Mon Apr 15 13:48:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 13:48:09 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v3]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <ohwlY2f69wykOw4yOEJ02Gr0oQjD_jAi6JRZsavE-O4=.e10e68ca-f02a-4f57-96c6-55f918a5b199@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

  Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/7de90243..e173ff09

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

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

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

From mcimadamore at openjdk.org  Mon Apr 15 13:54:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 13:54:44 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v3]
In-Reply-To: <ohwlY2f69wykOw4yOEJ02Gr0oQjD_jAi6JRZsavE-O4=.e10e68ca-f02a-4f57-96c6-55f918a5b199@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <ohwlY2f69wykOw4yOEJ02Gr0oQjD_jAi6JRZsavE-O4=.e10e68ca-f02a-4f57-96c6-55f918a5b199@github.com>
Message-ID: <zYxe2VpE1LLGI_dpgWKKvk7TZ9fwuLQhIHgIm9Mq85g=.6c40cf8e-9053-4a98-bc0c-ba9442669006@github.com>

On Mon, 15 Apr 2024 13:48:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 152:

> 150: 
> 151:     /**
> 152:      * Returns the address of the symbol with the given name or throws an Exception.

Suggestion:

     * Returns the address of the symbol with the given name or throws an exception.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1565837858

From pminborg at openjdk.org  Mon Apr 15 14:02:56 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 15 Apr 2024 14:02:56 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

  Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/e173ff09..fa86d837

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

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

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

From mcimadamore at openjdk.org  Mon Apr 15 14:48:01 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 15 Apr 2024 14:48:01 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
Message-ID: <yaXPZJz7zNPigYlPVl6JraAAIWWmGd8KE_9umn-m71U=.3e0367fd-f66d-4689-a593-3778a7a6730c@github.com>

On Mon, 15 Apr 2024 14:02:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2001319293

From jvernee at openjdk.org  Mon Apr 15 16:10:04 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 15 Apr 2024 16:10:04 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
Message-ID: <pZ7FQ20nyd2zTFvoqQxM9u4IvW6tzkk7AuGFacJfHv4=.4812ae1c-db82-4be6-923e-2fe40931d2c8@github.com>

On Mon, 15 Apr 2024 14:02:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2001521250

From abhiscxk at openjdk.org  Tue Apr 16 04:16:26 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 16 Apr 2024 04:16:26 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
Message-ID: <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>

> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
> 
> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
> 
> CI testing is green for the modified test. Link attached in JBS.

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

  Review comment update, tolerance check removed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18644/files
  - new: https://git.openjdk.org/jdk/pull/18644/files/170d45c1..d3a45209

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

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

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

From abhiscxk at openjdk.org  Tue Apr 16 04:16:26 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 16 Apr 2024 04:16:26 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <l3zam1cF7w16aPAu6ZeT_ERZM-86lRZV4a07We9sSGI=.5282f101-62b8-47d0-8062-822ae75ff004@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>
 <l3zam1cF7w16aPAu6ZeT_ERZM-86lRZV4a07We9sSGI=.5282f101-62b8-47d0-8062-822ae75ff004@github.com>
Message-ID: <gzIH4X_P0TGIkp3a6aey-QrdJWdrPBu70RCd3eUzMD8=.3fbe30b5-6042-4f9d-8d09-08a9b20d3c1c@github.com>

On Mon, 15 Apr 2024 08:34:43 GMT, Jayathirth D V <jdv at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update
>
> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 40:
> 
>> 38: import static java.awt.image.BufferedImage.TYPE_INT_ARGB;
>> 39: 
>> 40: /*
> 
> Usually we keep jtreg comment section before imports.

There was a discussion going on regarding placement of jtreg tags here https://corparch-core-srv.slack.com/archives/CNQ8SN9P1/p1707238824764849. We updated jtreg tags aftre imports section in recent test sprint.

So, kept it below imports.

> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 58:
> 
>> 56: 
>> 57:     private static void createCombo() {
>> 58:         combo = new JComboBox();
> 
> If we can use unicode blank character instead of "Simple JComboBox" text. I think we make this test more robust and avoid tolerance checks.

Updated.

> We are saving these images even in the case where test passes. In my local macOS run i see 16 images getting saved in JTwork folder. This will end up taking good amount of space in our CI test systems.
We should save image only in case of test failure foe debugging purpose.

Updated to save the image only when test fails.

> Also i see images with Mac OS X***.png filename and all of them are just blank and there is no combobox. Is that fine?

Even I also observed the same but not sure about this.

> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 125:
> 
>> 123:                 dColor2 = new Color(disabledImage2.getRGB(x + 1, y - 1));
>> 124:             } else if (lafName.equals("GTK+")) {
>> 125:                 // In GTK LAF, the ComboBox sizes are different and
> 
> Is there any way to get these internal offsets programmatically and not use constants?

Removed the offsets as after having unicode blank character there is no need of these.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1566678112
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1566680245
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1566682142
PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1566680611

From abhiscxk at openjdk.org  Tue Apr 16 05:55:42 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 16 Apr 2024 05:55:42 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
Message-ID: <UuSTCYdzRdo9tj6aOVdJ45MUJEfNFmgt9E5iAFMuQkU=.ef594f90-fe3d-45f3-a355-2ce61d13cbd3@github.com>

On Tue, 16 Apr 2024 04:16:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update, tolerance check removed

@jayathirthrao Ran the updated test in CI, no failure observed across platforms.

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

PR Comment: https://git.openjdk.org/jdk/pull/18644#issuecomment-2058282392

From jdv at openjdk.org  Tue Apr 16 06:55:00 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 16 Apr 2024 06:55:00 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
Message-ID: <J7PVVbcLFzNP7081X6S8c01hmp0QC3kgBGDOGjqdsHk=.8bab6afa-ec99-4a53-bc60-77bdf12bd665@github.com>

On Tue, 16 Apr 2024 04:16:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update, tolerance check removed

Updated changes look good to me.

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-2002750599

From serb at openjdk.org  Tue Apr 16 07:00:42 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 16 Apr 2024 07:00:42 GMT
Subject: RFR: 8289770: Remove Windows version macro from ShellFolder2.cpp
In-Reply-To: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
Message-ID: <IRqd0FLhXcPV9CywGlMHS0PfpfM91pkFyJ8kvm-r1cY=.e5aeb88e-a671-4449-9486-f4a75e2071a6@github.com>

On Thu, 11 Apr 2024 09:33:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
> 
> `IS_WINVISTA` was not used at all.
> 
> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.

src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 131:

> 129: #ifndef IS_WINVISTA
> 130: #define IS_WINVISTA (!(::GetVersion() & 0x80000000) && LOBYTE(LOWORD(::GetVersion())) >= 6)
> 131: #endif

there are exactly the same macro in awt.h which are mostly unused except "IS_WIN8"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18736#discussion_r1566819367

From serb at openjdk.org  Tue Apr 16 07:16:01 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 16 Apr 2024 07:16:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
Message-ID: <4Tqn_NILqWAu_5WY0oKDytmi7vQ69zWwEwKv0I9vdvs=.9b28b2a9-aabc-414e-b524-f19e91f2d6a3@github.com>

On Tue, 16 Apr 2024 04:16:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update, tolerance check removed

As far as I understand the test creates two enabled-JComboBox, then disables both, and then compares the disabled and enabled images. Why there are some differences in sizes and colors?

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

PR Comment: https://git.openjdk.org/jdk/pull/18644#issuecomment-2058394210

From serb at openjdk.org  Tue Apr 16 07:16:01 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 16 Apr 2024 07:16:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <gzIH4X_P0TGIkp3a6aey-QrdJWdrPBu70RCd3eUzMD8=.3fbe30b5-6042-4f9d-8d09-08a9b20d3c1c@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>
 <l3zam1cF7w16aPAu6ZeT_ERZM-86lRZV4a07We9sSGI=.5282f101-62b8-47d0-8062-822ae75ff004@github.com>
 <gzIH4X_P0TGIkp3a6aey-QrdJWdrPBu70RCd3eUzMD8=.3fbe30b5-6042-4f9d-8d09-08a9b20d3c1c@github.com>
Message-ID: <zwt53G2ZzsaNhDddip6Wns8Se6RJ4KgNuhkQJ_hS13A=.6285af4b-cd33-42f5-8b5b-7da850c6aa26@github.com>

On Tue, 16 Apr 2024 04:09:47 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 58:
>> 
>>> 56: 
>>> 57:     private static void createCombo() {
>>> 58:         combo = new JComboBox();
>> 
>> If we can use unicode blank character instead of "Simple JComboBox" text. I think we make this test more robust and avoid tolerance checks.
>
> Updated.

Can the initial bug "JComboBox has correct font color when disabled" be verified with this change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1566836859

From abhiscxk at openjdk.org  Tue Apr 16 09:31:42 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 16 Apr 2024 09:31:42 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <4Tqn_NILqWAu_5WY0oKDytmi7vQ69zWwEwKv0I9vdvs=.9b28b2a9-aabc-414e-b524-f19e91f2d6a3@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <4Tqn_NILqWAu_5WY0oKDytmi7vQ69zWwEwKv0I9vdvs=.9b28b2a9-aabc-414e-b524-f19e91f2d6a3@github.com>
Message-ID: <r9dp9WNO_rvvJ4TZ_AMx-RDe4tC48f0lO5CDRdZTpbI=.e25bbb88-9dd0-4d67-9927-5e14f7f16cb4@github.com>

On Tue, 16 Apr 2024 07:13:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> As far as I understand the test creates two enabled-JComboBox, then disables both, and then compares the disabled and enabled images. Why there are some differences in sizes and colors?

Not sure about this.. but there is a mention in initial bug also regarding size difference https://github.com/openjdk/jdk/pull/12390#issuecomment-1423241169

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

PR Comment: https://git.openjdk.org/jdk/pull/18644#issuecomment-2058649616

From abhiscxk at openjdk.org  Tue Apr 16 09:31:43 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 16 Apr 2024 09:31:43 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v2]
In-Reply-To: <zwt53G2ZzsaNhDddip6Wns8Se6RJ4KgNuhkQJ_hS13A=.6285af4b-cd33-42f5-8b5b-7da850c6aa26@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <YD1xI9wzqcwLL034bacPF6LZyN3tgLLRz0V0CLOMfnU=.5ae17f00-4b53-420b-99e1-92d3c52021eb@github.com>
 <l3zam1cF7w16aPAu6ZeT_ERZM-86lRZV4a07We9sSGI=.5282f101-62b8-47d0-8062-822ae75ff004@github.com>
 <gzIH4X_P0TGIkp3a6aey-QrdJWdrPBu70RCd3eUzMD8=.3fbe30b5-6042-4f9d-8d09-08a9b20d3c1c@github.com>
 <zwt53G2ZzsaNhDddip6Wns8Se6RJ4KgNuhkQJ_hS13A=.6285af4b-cd33-42f5-8b5b-7da850c6aa26@github.com>
Message-ID: <Slw7HdjYzheT0XvP_FLOUyX5D916Nye6UGgqF9p2SWw=.a619eba7-249e-4302-aac2-04dab2e4d6fd@github.com>

On Tue, 16 Apr 2024 07:13:02 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Updated.
>
> Can the initial bug "JComboBox has correct font color when disabled" be verified with this change?

This change works fine with initial bug. Test failed if I comment out the fix proposed in initial bug for Nimbus LAF.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1567043839

From ihse at openjdk.org  Tue Apr 16 09:52:19 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 16 Apr 2024 09:52:19 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D
 files [v2]
In-Reply-To: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
Message-ID: <U3VNi6GLJd51jjj35GEFWfxR6l9ipaFRwJHqk_X0jtE=.23294a9a-2437-4765-9100-38b5bfa00911@github.com>

> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
> 
> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

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

 - Merge branch 'master' into split-awt2d
 - 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18743/files
  - new: https://git.openjdk.org/jdk/pull/18743/files/81802740..49f1b4bf

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

  Stats: 7258 lines in 263 files changed: 3001 ins; 2087 del; 2170 mod
  Patch: https://git.openjdk.org/jdk/pull/18743.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18743/head:pull/18743

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

From ihse at openjdk.org  Tue Apr 16 10:03:27 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 16 Apr 2024 10:03:27 GMT
Subject: RFR: 8330107: Split Awt2dLibraries.gmk into separate AWT and 2D
 files [v3]
In-Reply-To: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
Message-ID: <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>

> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
> 
> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Make the split based on the name "awt" instead, and document the reason
 - Rename 2dLibraries.gmk to ClientLibraries.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18743/files
  - new: https://git.openjdk.org/jdk/pull/18743/files/49f1b4bf..de43e1e0

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

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

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

From ihse at openjdk.org  Tue Apr 16 10:05:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 16 Apr 2024 10:05:43 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
In-Reply-To: <Xlhwr9ECrwRBQIbnR-Jp5hxKzjxeWfWZSGoSvqjzS0k=.79063cdc-4c7f-40d8-a71c-042b0f84380d@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <pOcNXEgzeg24RQK-JuxAGrVcKggpX_-6C-0Z_VgDz0E=.c44aac4b-2f37-4c39-917d-50939a49dd91@github.com>
 <Xlhwr9ECrwRBQIbnR-Jp5hxKzjxeWfWZSGoSvqjzS0k=.79063cdc-4c7f-40d8-a71c-042b0f84380d@github.com>
Message-ID: <TSSGAHrdNO831OHzkPMZnYgpJVHhpxDCNdYoYNQQmz0=.1b61aac5-5f00-44e4-927c-1d007a52136c@github.com>

On Fri, 12 Apr 2024 22:44:35 GMT, Phil Race <prr at openjdk.org> wrote:

>> @prrace I will need your assistance in confirming that my understanding about the AWT vs 2D split is correct. In particular, `libosxui` gave me some headache, but after trying to dig into the code my understanding ended up being that this is part of Swing which is considered part of AWT, not 2D.
>> 
>> I also looked at `libosx` and `libosxapp` which are located in the general `Lib.gmk` file. I could not easily see that they should have been placed in either 2d or Awt, so my assumption is that they are correctly placed outside these two new files.
>
>> @prrace I will need your assistance in confirming that my understanding about the AWT vs 2D split is correct. In particular, `libosxui` gave me some headache, but after trying to dig into the code my understanding ended up being that this is part of Swing which is considered part of AWT, not 2D.
>> 
>> I also looked at `libosx` and `libosxapp` which are located in the general `Lib.gmk` file. I could not easily see that they should have been placed in either 2d or Awt, so my assumption is that they are correctly placed outside these two new files.
> 
> Swing isn't part of AWT. They are separate entities.
> Swing is built on top of 2D as much as it is built on top of AWT.
> 
> Any hope of finding a neat dividing line will be arbitrary and not really reflecting reality
> 
> And in some ways AWT is more closely tied to AWT than 2D is.
> 
> And things are not the same across platforms either.
> You've determined splashscreen is 2D functionality which it most certainly is not.
> 
> Awtlibraries is setting up the shaders which for the Metal rendering pipeline which is 100% 2D.
> 
> And it seems to be building OpenGL, etc as well ..
> 
> and generally I see so manay references to 2D in the AWT file and vice versa.
> 
> it isn't even true that "libawt" is awt. Libawt  is mostly a misnomer, in one case more than mostly. It ought to be called "lib2d"
> 
> So I think this change will just cause confusion and doesn't seem right to me. It ought to "not happen".

@prrace I tried implementing my suggestion: making the split based purely on having "awt" in the library name. I also clearly documented that the reason for the split do not imply anything about the source code. Would this be okay to you?

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2058714191

From aivanov at openjdk.org  Tue Apr 16 11:30:00 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 16 Apr 2024 11:30:00 GMT
Subject: RFR: 8289770: Remove Windows version macro from ShellFolder2.cpp
In-Reply-To: <IRqd0FLhXcPV9CywGlMHS0PfpfM91pkFyJ8kvm-r1cY=.e5aeb88e-a671-4449-9486-f4a75e2071a6@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
 <IRqd0FLhXcPV9CywGlMHS0PfpfM91pkFyJ8kvm-r1cY=.e5aeb88e-a671-4449-9486-f4a75e2071a6@github.com>
Message-ID: <MKGYXpW59flfJV0o71QNRbDF1kPSgGo-zG2l1iNNSAA=.cf063118-e1c7-4c50-9f84-f64ed0a37060@github.com>

On Tue, 16 Apr 2024 06:58:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
>> 
>> `IS_WINVISTA` was not used at all.
>> 
>> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.
>
> src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp line 131:
> 
>> 129: #ifndef IS_WINVISTA
>> 130: #define IS_WINVISTA (!(::GetVersion() & 0x80000000) && LOBYTE(LOWORD(::GetVersion())) >= 6)
>> 131: #endif
> 
> there are exactly the same macro in awt.h which are mostly unused except "IS_WIN8"

There's a separate bug for removing the macro from `awt.h`:

[JDK-8289772](https://bugs.openjdk.org/browse/JDK-8289772): Remove obsolete Windows version macros: IS_WIN2000, IS_WINXP, IS_WINVISTA

Why am I taking `ShellFolder2.cpp` separately? The comment in the `ShellFolder2.cpp` file suggest these are copies from `awt.h`. This makes `ShellFolder2.cpp` isolated from any other usage. Removing the macro cleans up a single file, easy to do, easy to review.

Removing the macro from `awt.h` is not as simple, some macro are used in the code. For example, `IS_WIN8` is used in `awt_Toolkit.cpp` to determine whether touch keyboard handling is enabled.

https://github.com/openjdk/jdk/blob/58911ccc2c48b4b5dd2ebc9d2a44dcf3737eca50/src/java.desktop/windows/native/libawt/windows/awt_Toolkit.cpp#L669

Then `IS_WINVISTA` is used in the code which determines whether DWM is available; `IS_WINXP` is used in many places to determine menu bar colors, to handle subclassing default Windows controls. Removing the macro will make the code cleaner but it requires modifying the code. Eventually, the task may be broken into smaller pieces.

The usage of `IS_WIN8` could be replaced with [`IsWindows8OrGreater`](https://learn.microsoft.com/en-us/windows/win32/api/VersionHelpers/nf-versionhelpers-iswindows8orgreater) which is part of [Version Helper functions](https://learn.microsoft.com/en-us/windows/win32/sysinfo/version-helper-apis) and is the recommended method to determine the version of the Windows OS.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18736#discussion_r1567192769

From jvernee at openjdk.org  Tue Apr 16 14:14:03 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 16 Apr 2024 14:14:03 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v4]
In-Reply-To: <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <5xcpEj85UX0BJUK8vYDDXymSvB9MrVjXOCCmUlyVE9k=.86e0b7c5-edf9-47a9-83eb-9dac4570935c@github.com>
Message-ID: <OvTATV03nGgwnaa2FAkfK1fbWIbbq-XvpqvzDsgH7rU=.477dd0bd-ab01-41d3-9b0c-57cd82e9ab1c@github.com>

On Mon, 15 Apr 2024 14:02:56 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

src/java.base/share/classes/java/lang/foreign/package-info.java line 114:

> 112:  *
> 113:  * Here, we obtain a {@linkplain java.lang.foreign.Linker#nativeLinker() native linker}
> 114:  * and we use it to {@linkplain java.lang.foreign.SymbolLookup#findOrThrow(java.lang.String)}

Looks like the plain text was dropped here:
Suggestion:

 * and we use it to {@linkplain java.lang.foreign.SymbolLookup#findOrThrow(java.lang.String) look up}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1567435862

From abhiscxk at openjdk.org  Tue Apr 16 17:00:44 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 16 Apr 2024 17:00:44 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v4]
In-Reply-To: <CvY9IP_u5ooinIHxAGmC03VnJYWnRemIqOMQwGr0i3E=.e1cebff7-2429-4464-8dee-92c3c016145b@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <QNyJ-3Z_mL-93xX-i9M_dfRv68fJ3NXKqz0uCvD6v5I=.38160411-9cec-469a-8de8-ad6c0ceb38c8@github.com>
 <CvY9IP_u5ooinIHxAGmC03VnJYWnRemIqOMQwGr0i3E=.e1cebff7-2429-4464-8dee-92c3c016145b@github.com>
Message-ID: <kVEsnRD-oAq7_jRpleZxzz-KQTajCUDBvnFDygHaykQ=.f0c79ea9-2789-4c75-89c5-d95860f88222@github.com>

On Mon, 1 Apr 2024 21:29:09 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   condition combined
>
> Changes requested by honkar (Reviewer).

@honkar-jdk There are few changes after you last reviewed. Please review the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/17720#issuecomment-2059538983

From prr at openjdk.org  Tue Apr 16 18:09:00 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 16 Apr 2024 18:09:00 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
 [v3]
In-Reply-To: <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
Message-ID: <M9-COHTyQtzcnfb1O-8-srv_Tx9386ICMeEEQie9bjw=.b0cd2576-456e-4fe8-b6a6-06c9a67a86ca@github.com>

On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>> 
>> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make the split based on the name "awt" instead, and document the reason
>  - Rename 2dLibraries.gmk to ClientLibraries.gmk

I still find this artificial, arbitrary, inconsistent, and even wrong.
The name "awt" in a library isn't a good way to divide it, but I don't have an alternative proposal
because there is no good way to divide it.
And I just don't agree with the premise. Or at least it is far outweighed by everything else.
I see it just sowing confusion and having to change 2 files etc.
So I don't support this change in any variation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2059664922

From ihse at openjdk.org  Tue Apr 16 18:37:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 16 Apr 2024 18:37:59 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
 [v3]
In-Reply-To: <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
Message-ID: <UdOnik03ALxt-68N4W8L75731jDo0rRv9pB0IE1sksM=.c6265d54-5103-403f-9f93-2f21bc1c5bba@github.com>

On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>> 
>> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make the split based on the name "awt" instead, and document the reason
>  - Rename 2dLibraries.gmk to ClientLibraries.gmk

**I** am the one working with this file all the time, not you. There is no good IDE support for Makefiles, especially not with the level of customization that we have done to make. I am positively struggling with navigating this file, time and time again.

Can that not be enough reason for you to accept that I want to split this file into more manageable chunks? Nothing here will affect how the actual client libraries are built. It is *purely* about making this part of the JDK build less of a complete PITA for me. Why are you opposing this? I tried two different approaches, and suggested a third (alphabetic) and you just say "no".  I don't find this very constructive or helpful.

This is not the first time we split a makefile into "arbitrary" chunks. Since make is not a proper programming language, there is no way to express abstraction, objects or other clear delimiters. The most recently file that was split this way was JdkNativeCompilation.gmk. One of the first was configure.ac. All those split were "arbitrary" and "artificial", but they are still good enough to provide help to the poor sods that need to work with those files.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2059708051

From ihse at openjdk.org  Tue Apr 16 18:46:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 16 Apr 2024 18:46:00 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
 [v3]
In-Reply-To: <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
Message-ID: <7WhYZucmWOpro6BaMe5yniONsmhZrKNsMII_d7mtZv8=.5bcd2da8-4726-4b6f-85b9-21084048f1d3@github.com>

On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>> 
>> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make the split based on the name "awt" instead, and document the reason
>  - Rename 2dLibraries.gmk to ClientLibraries.gmk

And just to put some perspective here: The .gmk files for all other modules are at an average of 2 kB. The Awt2dLibraries.gmk file is 32 kB. Even with the split the two remaining parts will be 16 kB, which is still larger than the next biggest file (java.base/gensrc/GensrcBuffer.gmk) at 14 kB. So this is really an outlier.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2059720604

From prr at openjdk.org  Tue Apr 16 18:53:42 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 16 Apr 2024 18:53:42 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
 [v3]
In-Reply-To: <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
Message-ID: <he5EtyrGo3ZTCSSxFa3svOQfSWVqjvpuonYjzvPme6U=.5ceee8b1-6340-4bda-b205-afb5295d597b@github.com>

On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>> 
>> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make the split based on the name "awt" instead, and document the reason
>  - Rename 2dLibraries.gmk to ClientLibraries.gmk

I appreciate that the build group does a lot of work maintaining this file.
I'd like to think that even though it is a build file, it is build file for the desktop module, so I have skin in this game.
I am coming at it from the point of view of what makes sense (at least to me).
Even if I was the maintainer of this file, working on it every day, I wouldn't think splitting it any kind of priority.

So I need to be clear, if you REALLY want to do this, then I won't stop you, I just think it is the wrong thing to do.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2059731122

From dnguyen at openjdk.org  Tue Apr 16 19:51:03 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 16 Apr 2024 19:51:03 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
Message-ID: <T64P9xhbvrByiBX1EsRlNZWSnuqq5BgnVyRI6hkT0V0=.6fd5b76b-1ac2-4494-82c7-b8b22573bf3f@github.com>

On Tue, 16 Apr 2024 04:16:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update, tolerance check removed

Updated changes LGTM

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-2004479697

From tr at openjdk.org  Wed Apr 17 04:09:01 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Apr 2024 04:09:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
Message-ID: <9EMpF-TQSE6qntUDPvvgjnwW59KFSbIemyFC6MyMBoA=.348ca958-572c-47be-bad0-90bd84e4ce90@github.com>

On Tue, 16 Apr 2024 04:16:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update, tolerance check removed

I guess `testDir` can be moved inside `testMethod()` method where it is used.

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

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-2004975246

From abhiscxk at openjdk.org  Wed Apr 17 04:31:16 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Apr 2024 04:31:16 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v4]
In-Reply-To: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
Message-ID: <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>

> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
> 
> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
> 
> CI testing is green for the modified test. Link attached in JBS.

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

  testDir moved to method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18644/files
  - new: https://git.openjdk.org/jdk/pull/18644/files/d3a45209..5e7bcf37

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

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

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

From tr at openjdk.org  Wed Apr 17 04:31:16 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Apr 2024 04:31:16 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
Message-ID: <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>

On Tue, 16 Apr 2024 04:16:26 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment update, tolerance check removed

test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 125:

> 123:     private static boolean isColorMatching(Color c1, Color c2) {
> 124:         if ((c1.getRed() != c2.getRed())
> 125:             || (c1.getBlue() != c2.getBlue())

This condition can be optimized since the test is done for all LAF and for each this method is called twice. Instead of using ||, using && would optimized slightly. You can check for `true` where it checks for `==` and returns true. Its just a suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1568197384

From abhiscxk at openjdk.org  Wed Apr 17 04:38:01 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Apr 2024 04:38:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <9EMpF-TQSE6qntUDPvvgjnwW59KFSbIemyFC6MyMBoA=.348ca958-572c-47be-bad0-90bd84e4ce90@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <9EMpF-TQSE6qntUDPvvgjnwW59KFSbIemyFC6MyMBoA=.348ca958-572c-47be-bad0-90bd84e4ce90@github.com>
Message-ID: <hNprLz31JbZw4Zg6J7lB1Cc2iGlVXTYXnCMQHfSwRJw=.bf33f95c-a4a9-49c9-b87a-7bc4f53ca9ae@github.com>

On Wed, 17 Apr 2024 04:06:34 GMT, Tejesh R <tr at openjdk.org> wrote:

> I guess `testDir` can be moved inside `testMethod()` method where it is used.

Updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/18644#issuecomment-2060326726

From abhiscxk at openjdk.org  Wed Apr 17 05:20:01 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Apr 2024 05:20:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>
Message-ID: <kURUn2dGC8SX3HfCi4U98DFS8vab-rB6jLroXSXQDko=.edd001e0-c3a1-4b4a-8044-95a17097b62e@github.com>

On Wed, 17 Apr 2024 04:25:43 GMT, Tejesh R <tr at openjdk.org> wrote:

> This condition can be optimized since the test is done for all LAF and for each this method is called twice. Instead of using ||, using && would optimized slightly. You can check for `true` where it checks for `==` and returns true. Its just a suggestion.

I think current comparison with || is ok as if any of the RGB color component doesn't match, test should fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1568225972

From tr at openjdk.org  Wed Apr 17 05:49:01 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Apr 2024 05:49:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <kURUn2dGC8SX3HfCi4U98DFS8vab-rB6jLroXSXQDko=.edd001e0-c3a1-4b4a-8044-95a17097b62e@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>
 <kURUn2dGC8SX3HfCi4U98DFS8vab-rB6jLroXSXQDko=.edd001e0-c3a1-4b4a-8044-95a17097b62e@github.com>
Message-ID: <FwkYki7c5_JQpDg6p5SwT-tPlTuFOgfzgreg6Y7zGiQ=.d254e715-bce5-43cb-88a5-172982b04d30@github.com>

On Wed, 17 Apr 2024 05:17:03 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/javax/swing/JComboBox/DisabledComboBoxFontTestAuto.java line 125:
>> 
>>> 123:     private static boolean isColorMatching(Color c1, Color c2) {
>>> 124:         if ((c1.getRed() != c2.getRed())
>>> 125:             || (c1.getBlue() != c2.getBlue())
>> 
>> This condition can be optimized since the test is done for all LAF and for each this method is called twice. Instead of using ||, using && would optimized slightly. You can check for `true` where it checks for `==` and returns true. Its just a suggestion.
>
>> This condition can be optimized since the test is done for all LAF and for each this method is called twice. Instead of using ||, using && would optimized slightly. You can check for `true` where it checks for `==` and returns true. Its just a suggestion.
> 
> I think current comparison with || is ok as if any of the RGB color component doesn't match, test should fail.

I meant to use `&&` so that comparisons for failure case fails faster than `||`. 
Similar to this:
` if ((c1.getRed() == c2.getRed())
            && (c1.getBlue() == c2.getBlue())
            && (c1.getGreen() == c2.getGreen())) {
           return true;

} else {

 System.out.println(lafName + " Enabled RGB failure: "
                    + c1.getRed() + ", "
                    + c1.getBlue() + ", "
                    + c1.getGreen() + " vs "
                    + c2.getRed() + ", "
                    + c2.getBlue() + ", "
                    + c2.getGreen());
            return false;
 }`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1568256649

From abhiscxk at openjdk.org  Wed Apr 17 06:11:42 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Apr 2024 06:11:42 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <FwkYki7c5_JQpDg6p5SwT-tPlTuFOgfzgreg6Y7zGiQ=.d254e715-bce5-43cb-88a5-172982b04d30@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>
 <kURUn2dGC8SX3HfCi4U98DFS8vab-rB6jLroXSXQDko=.edd001e0-c3a1-4b4a-8044-95a17097b62e@github.com>
 <FwkYki7c5_JQpDg6p5SwT-tPlTuFOgfzgreg6Y7zGiQ=.d254e715-bce5-43cb-88a5-172982b04d30@github.com>
Message-ID: <9h_Kj_ah3GA-moPvfhXBTH9HaM3oG41WekLb185-KKs=.066da888-8ae5-4f34-adda-90f3bcff7d65@github.com>

On Wed, 17 Apr 2024 05:45:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> This condition can be optimized since the test is done for all LAF and for each this method is called twice. Instead of using ||, using && would optimized slightly. You can check for `true` where it checks for `==` and returns true. Its just a suggestion.
>> 
>> I think current comparison with || is ok as if any of the RGB color component doesn't match, test should fail.
>
> I meant to use `&&` so that comparisons for failure case fails faster than `||`. 
> Similar to this:
> ` if ((c1.getRed() == c2.getRed())
>             && (c1.getBlue() == c2.getBlue())
>             && (c1.getGreen() == c2.getGreen())) {
>            return true;
> 
> } else {
> 
>  System.out.println(lafName + " Enabled RGB failure: "
>                     + c1.getRed() + ", "
>                     + c1.getBlue() + ", "
>                     + c1.getGreen() + " vs "
>                     + c2.getRed() + ", "
>                     + c2.getBlue() + ", "
>                     + c2.getGreen());
>             return false;
>  }`

The logical || operator doesn't check second condition if first condition is true. It checks second condition only if first one is false.
So as per current logic, if RED component is not equal, it doesn't check for GREEN and BLUE component and fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1568274603

From tr at openjdk.org  Wed Apr 17 06:24:00 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Apr 2024 06:24:00 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <9h_Kj_ah3GA-moPvfhXBTH9HaM3oG41WekLb185-KKs=.066da888-8ae5-4f34-adda-90f3bcff7d65@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>
 <kURUn2dGC8SX3HfCi4U98DFS8vab-rB6jLroXSXQDko=.edd001e0-c3a1-4b4a-8044-95a17097b62e@github.com>
 <FwkYki7c5_JQpDg6p5SwT-tPlTuFOgfzgreg6Y7zGiQ=.d254e715-bce5-43cb-88a5-172982b04d30@github.com>
 <9h_Kj_ah3GA-moPvfhXBTH9HaM3oG41WekLb185-KKs=.066da888-8ae5-4f34-adda-90f3bcff7d65@github.com>
Message-ID: <4nou2mrT7XMskIJxqWzCdoyy7qI6olMx8L8s45HrFS0=.881d191d-b94a-4a68-b204-37596efa01c5@github.com>

On Wed, 17 Apr 2024 06:09:32 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> I meant to use `&&` so that comparisons for failure case fails faster than `||`. 
>> Similar to this:
>> ` if ((c1.getRed() == c2.getRed())
>>             && (c1.getBlue() == c2.getBlue())
>>             && (c1.getGreen() == c2.getGreen())) {
>>            return true;
>> 
>> } else {
>> 
>>  System.out.println(lafName + " Enabled RGB failure: "
>>                     + c1.getRed() + ", "
>>                     + c1.getBlue() + ", "
>>                     + c1.getGreen() + " vs "
>>                     + c2.getRed() + ", "
>>                     + c2.getBlue() + ", "
>>                     + c2.getGreen());
>>             return false;
>>  }`
>
> The logical || operator doesn't check second condition if first condition is true. It checks second condition only if first one is false.
> So as per current logic, if RED component is not equal, it doesn't check for GREEN and BLUE component and fails.

Exactly, similar thing applies to && and hence in failure condition || checks for all the colors while && drops off at first failure only. Which is why I suggested it would be better for failure cases.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1568282858

From tr at openjdk.org  Wed Apr 17 06:28:01 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Apr 2024 06:28:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v4]
In-Reply-To: <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
Message-ID: <6v0bMAeMeAOK1ubuGQrjXFlT5MAsMgn6OKnsn2XgakU=.083a1e0f-69f0-4b1d-b211-c1360f1cc6f1@github.com>

On Wed, 17 Apr 2024 04:31:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   testDir moved to method

LGTM

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-2005144438

From abhiscxk at openjdk.org  Wed Apr 17 06:28:02 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Apr 2024 06:28:02 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <6CE0LexJbqRYmWCRyardg0MYupKM1Uy0smrFmAqtSsI=.7a69df56-7b7a-4346-b2b0-8651157ff4b8@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>
 <kURUn2dGC8SX3HfCi4U98DFS8vab-rB6jLroXSXQDko=.edd001e0-c3a1-4b4a-8044-95a17097b62e@github.com>
 <FwkYki7c5_JQpDg6p5SwT-tPlTuFOgfzgreg6Y7zGiQ=.d254e715-bce5-43cb-88a5-172982b04d30@github.com>
 <9h_Kj_ah3GA-moPvfhXBTH9HaM3oG41WekLb185-KKs=.066da888-8ae5-4f34-adda-90f3bcff7d65@github.com>
 <4nou2mrT7XMskIJxqWzCdoyy7qI6olMx8L8s45HrFS0=.881d191d-b94a-4a68-b204-37596efa01c5@github.com>
 <6CE0LexJbqRYmWCRyardg0MYupKM1Uy0smrFmAqtSsI=.7a69df56-7b7a-4346-b2b0-8651157ff4b8@github.com>
Message-ID: <l3faD4p37Ls5e5ONw3pjnoNB2yEUjckx-SddQeXz-qo=.0c232f7e-ae1e-4345-aaaf-3a3dce9b2c11@github.com>

On Wed, 17 Apr 2024 06:24:51 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Exactly, similar thing applies to && and hence in failure condition || checks for all the colors while && drops off at first failure only. Which is why I suggested it would be better for failure cases.
>
> Yeah, its `!=` here right, then it'll fail fast for failure conditions...... Then no need to optimize......

In && operator if condition evaluate to false it will not check further.
Similarly, in || operator if condition evaluate to true it will not check further.
So if c1.getRed() != c2.getRed() evaluates to true, it will not check further and fail immediately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1568288763

From tr at openjdk.org  Wed Apr 17 06:28:01 2024
From: tr at openjdk.org (Tejesh R)
Date: Wed, 17 Apr 2024 06:28:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <4nou2mrT7XMskIJxqWzCdoyy7qI6olMx8L8s45HrFS0=.881d191d-b94a-4a68-b204-37596efa01c5@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <Gjbg6DxH_kFrIsBhqHNgFsXAR2mzRLUIpJ_4ratRi_0=.ad49e7cd-65b5-4aea-8722-6add739fdb38@github.com>
 <kURUn2dGC8SX3HfCi4U98DFS8vab-rB6jLroXSXQDko=.edd001e0-c3a1-4b4a-8044-95a17097b62e@github.com>
 <FwkYki7c5_JQpDg6p5SwT-tPlTuFOgfzgreg6Y7zGiQ=.d254e715-bce5-43cb-88a5-172982b04d30@github.com>
 <9h_Kj_ah3GA-moPvfhXBTH9HaM3oG41WekLb185-KKs=.066da888-8ae5-4f34-adda-90f3bcff7d65@github.com>
 <4nou2mrT7XMskIJxqWzCdoyy7qI6olMx8L8s45HrFS0=.881d191d-b94a-4a68-b204-37596efa01c5@github.com>
Message-ID: <6CE0LexJbqRYmWCRyardg0MYupKM1Uy0smrFmAqtSsI=.7a69df56-7b7a-4346-b2b0-8651157ff4b8@github.com>

On Wed, 17 Apr 2024 06:18:39 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The logical || operator doesn't check second condition if first condition is true. It checks second condition only if first one is false.
>> So as per current logic, if RED component is not equal, it doesn't check for GREEN and BLUE component and fails.
>
> Exactly, similar thing applies to && and hence in failure condition || checks for all the colors while && drops off at first failure only. Which is why I suggested it would be better for failure cases.

Yeah, its `!=` here right, then it'll fail fast for failure conditions...... Then no need to optimize......

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18644#discussion_r1568288421

From abhiscxk at openjdk.org  Wed Apr 17 09:59:01 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 17 Apr 2024 09:59:01 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <r9dp9WNO_rvvJ4TZ_AMx-RDe4tC48f0lO5CDRdZTpbI=.e25bbb88-9dd0-4d67-9927-5e14f7f16cb4@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <4Tqn_NILqWAu_5WY0oKDytmi7vQ69zWwEwKv0I9vdvs=.9b28b2a9-aabc-414e-b524-f19e91f2d6a3@github.com>
 <r9dp9WNO_rvvJ4TZ_AMx-RDe4tC48f0lO5CDRdZTpbI=.e25bbb88-9dd0-4d67-9927-5e14f7f16cb4@github.com>
Message-ID: <_6nFlCFX8bHDS94eor1fCKQW38z5zpA5BqKU40JeIoY=.dc5b576f-9f2e-4785-9d52-f6ddbec782f7@github.com>

On Tue, 16 Apr 2024 09:29:03 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> As far as I understand the test creates two enabled-JComboBox, then disables both, and then compares the disabled and enabled images. Why there are some differences in sizes and colors?

Difference in size is specific to LAFs like in case on Metal and Motif the sizes are same but in Nimbus and GTK it differs in size.
For Nimbus when DefaultListCellRenderer is used the width is 2px more than when SynthComboBoxRenderer is used. This is due to the difference in Inset values. In case of DefaultListCellRenderer the Insets value (left and right) are 1 px more than the insets value for SynthComboBoxRenderer.

Similarly in GTK LAF also the insets values are different in DefaultListCellRenderer  and SynthComboBoxRenderer.

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

PR Comment: https://git.openjdk.org/jdk/pull/18644#issuecomment-2060871022

From pminborg at openjdk.org  Wed Apr 17 11:24:28 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 17 Apr 2024 11:24:28 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v5]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <nG3gW3IfgyIcZuOq6igDvfWcW2T3D4QCl3EcCYnDMzs=.dccd37db-c186-49e3-9245-50a90c17db64@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

  Update src/java.base/share/classes/java/lang/foreign/package-info.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/fa86d837..2ebac9fc

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

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

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

From erikj at openjdk.org  Wed Apr 17 12:32:43 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 17 Apr 2024 12:32:43 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
 [v3]
In-Reply-To: <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
Message-ID: <79xD6pvDwtSM5MLRjDzjPzFABNCLGJM3b34gcBKOTCw=.fa94699c-5541-44b5-b305-61921deba475@github.com>

On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>> 
>> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make the split based on the name "awt" instead, and document the reason
>  - Rename 2dLibraries.gmk to ClientLibraries.gmk

This looks good to me. The split may be arbitrary from a functional point of view, but will make navigating the makefiles easier.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18743#pullrequestreview-2005913700

From ihse at openjdk.org  Wed Apr 17 12:42:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Apr 2024 12:42:03 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
 [v3]
In-Reply-To: <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
Message-ID: <XtfS8LF5yWjEM1-80K-8ajWfI-CIk4w7BTklnSpbMDE=.97b0821c-700a-4703-a854-2dcc2f0d3ab9@github.com>

On Tue, 16 Apr 2024 10:03:27 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
>> 
>> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Make the split based on the name "awt" instead, and document the reason
>  - Rename 2dLibraries.gmk to ClientLibraries.gmk

Yes, I really want to do this. I am sorry that we could not reach an agreement, but I need to be able to work with these files in a better way than is currently possible.

Thanks Erik and Phil.

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2061165564

From ihse at openjdk.org  Wed Apr 17 12:42:04 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 17 Apr 2024 12:42:04 GMT
Subject: Integrated: 8330107: Separate out "awt" libraries from
 Awt2dLibraries.gmk
In-Reply-To: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
Message-ID: <bBszfxKxTL0klelv_7COKhg2IV8nI6nQJKVyVsWf_SM=.93c38a32-2507-4de4-b17d-c5e60f96ee16@github.com>

On Thu, 11 Apr 2024 13:53:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The file to build most of the java.desktop native libraries, Awt2dLibraries.gmk, is large and unstructured, making it hard to navigate.
> 
> I want to split it into two parts, one for the AWT libraries, and one for the 2D libraries. I also used this opportunity to change the order to be more logical (e.g. grouping "image" libraries and "font" libraries in 2D).

This pull request has now been integrated.

Changeset: 5841cb3b
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5841cb3b51e45e7c3aaa086e179815fa8184f22d
Stats:     1724 lines in 4 files changed: 880 ins; 843 del; 1 mod

8330107: Separate out "awt" libraries from Awt2dLibraries.gmk

Reviewed-by: erikj

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

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

From aivanov at openjdk.org  Wed Apr 17 14:29:01 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 17 Apr 2024 14:29:01 GMT
Subject: RFR: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame [v2]
In-Reply-To: <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
 <9XR2AYKvw8a2dCgyjhjOVpCC58evDFrzGr4loS6uHRQ=.d932860f-d34d-401a-b34e-340884541e9a@github.com>
Message-ID: <Iz3BYH4GmmssvHkluncgNk8jzHD1_wn0WzWF-cVzSTU=.330e23e4-b44d-4a6b-81f5-207c22ada1d8@github.com>

On Mon, 8 Apr 2024 07:57:11 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
>> 
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated insturction style
>  - Updated suggesions

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18624#pullrequestreview-2006210796

From prr at openjdk.org  Wed Apr 17 20:13:01 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 17 Apr 2024 20:13:01 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS
In-Reply-To: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
References: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
Message-ID: <WHls4HJmu4_EQXV7PlhhBvtdEZlkaSVlVDbQxdDUFUI=.72b3d700-7c90-49e9-b819-bf087d85710b@github.com>

On Mon, 11 Mar 2024 13:54:02 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> The fix provides ability to print Black & White pages on macOS.
> 
> Cocoa API has [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode) function but it is marked as deprecated and really does nothing.
> 
> There is no replacement; this function was included to facilitate porting legacy applications to macOS, 
> but it serves no useful purpose.
> 
> Dumping `NSPrintInfo` print settings which were set by the native print dialog on macOS shows that the keys and values used for Black & White printing depend on the used printer type.
> For example, the tested 
> `HP Color LaserJet MFP M180n` printer uses `ColorModel` key and`Gray` value, and
> `HP Ink Tank 110 series` uses `HPColorMode` key and `grayscale` value.
> 
> Printing all `NSPrintInfo` presets shows that they do not contain key/value pairs  for Black&White settings.
> This is the code snippet used to print `NSPrintInfo` presets:
> 
>     PMPrinter pr;
>     PMPrintSession printSession = (PMPrintSession)[printInfo PMPrintSession];
>     OSStatus status = PMSessionGetCurrentPrinter(printSession, &pr);
>     CFArrayRef presetsList = nil;
>     status = PMPrinterCopyPresets(pr, &presetsList);
>     CFIndex arrayCount = CFArrayGetCount(presetsList);
> 
>     for (CFIndex index = 0; index < arrayCount; index++) {
>         PMPreset preset = (PMPreset)CFArrayGetValueAtIndex(presetsList, index);
>         CFStringRef presetName = nil;
>         if (PMPresetCopyName(preset, &presetName) == noErr && CFStringGetLength(presetName) > 0) {
>             NSLog(@"  presetName: '%@'", presetName);
>             NSDictionary* dict = nil;
>             if (PMPresetGetAttributes(preset, (CFDictionaryRef*)(&dict)) == noErr) {
>                    // print preset dict
> 
> 
> The idea of the proposed fix is to store printer dependent key/value pairs in the `<jdk-home>/conf/printer.properties` property file.
> 
> The property file has the format:
> 
> print-attribute.print-attribute-value.key=value
> 
> where `print-attribute` is the java print attribute, `print-attribute-value` is the corresponding attribute value, and `key` and `value` is the key/value pair used by a specific printer.
> 
> For example, for `Chromaticity` attribute the property file could look like:
> 
> Chromaticity.MONOCHROME.ColorModel=Gray
> Chromaticity.COLOR.ColorModel=CMYK
> Chromaticity.MONOCHROME.HPColorMode=grayscale
> Chromaticity.COLOR.HPColorMode=color
> 
> where `Chromaticity.MONOCHROME` key prefix corresponds to `Chromaticity.MONOCHOROME` print attribute constant  with  (...

src/java.desktop/macosx/native/libawt_lwawt/awt/CPrinterJob.m line 551:

> 549: 
> 550:         if (chromaticityKeyValues == nil) {
> 551: 

I'm not trying to revive this PR, but I was looking at it and I got curious about a couple of things.
What is going on here ?
First the Java code will never (I think) return NULL, so the "if" will never be used.
Second, why in the case that it does, did you decide to set ColorModel=Gray or ColorModel=Color ?
Are these a best guess default ? In which case why don't you always specify them anyway ?
You are already throwing the entire set of ones you read from the conf file into the settings.

Also there's no way I can see for you to KNOW that the settings will work. 
This could be confusing for apps wanting monochrome/gray 
Since you don't report back the supported status then they can't tell that when monochrome would work.

and (btw) you don't even filter this by whether the printer supports color when setting Color.

And on a broader note, the entire PPD API and PPD printer drivers are deprecated by CUPS.
So this seems like an approach on which the clock is ticking before it is even deployed.

test/jdk/javax/print/attribute/ChromaticityAttributeTest.java line 168:

> 166:     }
> 167: 
> 168:     private static Set<Chromaticity> getSupportedChromaticityAttributes() {

The presence of this method is misleading in the test.
You don't use it and just hard code Color + Monochrome in what you test.
And in fact I don't see anywhere you've updated the implementation to report supported values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18195#discussion_r1569463240
PR Review Comment: https://git.openjdk.org/jdk/pull/18195#discussion_r1569440468

From prr at openjdk.org  Wed Apr 17 20:44:01 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 17 Apr 2024 20:44:01 GMT
Subject: RFR: 8315113: Print request Chromaticity.MONOCHROME attribute does
 not work on macOS
In-Reply-To: <9NaQ7MzCph2B2CYYqk_o_yMqLtOz45sWsq8fbCk67Es=.d278e2e4-2dfe-499f-913f-b7ec47e577b9@github.com>
References: <m_OJNAf9YmC4OJMwtCM5P-eklmNJUymWJjMfo5s_wpI=.7d1c5a1f-2158-49f2-906d-dc074019cb99@github.com>
 <9NaQ7MzCph2B2CYYqk_o_yMqLtOz45sWsq8fbCk67Es=.d278e2e4-2dfe-499f-913f-b7ec47e577b9@github.com>
Message-ID: <xOn7q67sEMjadpV67I2hkls-6_d02IeX69AaS0yce6w=.b14303fc-416f-47a8-920b-f12e4c1ce03e@github.com>

On Mon, 8 Apr 2024 23:19:13 GMT, Phil Race <prr at openjdk.org> wrote:

>> The fix provides ability to print Black & White pages on macOS.
>> 
>> Cocoa API has [PMSetColorMode](https://developer.apple.com/documentation/applicationservices/core_printing/1805783-pmsetcolormode) function but it is marked as deprecated and really does nothing.
>> 
>> There is no replacement; this function was included to facilitate porting legacy applications to macOS, 
>> but it serves no useful purpose.
>> 
>> Dumping `NSPrintInfo` print settings which were set by the native print dialog on macOS shows that the keys and values used for Black & White printing depend on the used printer type.
>> For example, the tested 
>> `HP Color LaserJet MFP M180n` printer uses `ColorModel` key and`Gray` value, and
>> `HP Ink Tank 110 series` uses `HPColorMode` key and `grayscale` value.
>> 
>> Printing all `NSPrintInfo` presets shows that they do not contain key/value pairs  for Black&White settings.
>> This is the code snippet used to print `NSPrintInfo` presets:
>> 
>>     PMPrinter pr;
>>     PMPrintSession printSession = (PMPrintSession)[printInfo PMPrintSession];
>>     OSStatus status = PMSessionGetCurrentPrinter(printSession, &pr);
>>     CFArrayRef presetsList = nil;
>>     status = PMPrinterCopyPresets(pr, &presetsList);
>>     CFIndex arrayCount = CFArrayGetCount(presetsList);
>> 
>>     for (CFIndex index = 0; index < arrayCount; index++) {
>>         PMPreset preset = (PMPreset)CFArrayGetValueAtIndex(presetsList, index);
>>         CFStringRef presetName = nil;
>>         if (PMPresetCopyName(preset, &presetName) == noErr && CFStringGetLength(presetName) > 0) {
>>             NSLog(@"  presetName: '%@'", presetName);
>>             NSDictionary* dict = nil;
>>             if (PMPresetGetAttributes(preset, (CFDictionaryRef*)(&dict)) == noErr) {
>>                    // print preset dict
>> 
>> 
>> The idea of the proposed fix is to store printer dependent key/value pairs in the `<jdk-home>/conf/printer.properties` property file.
>> 
>> The property file has the format:
>> 
>> print-attribute.print-attribute-value.key=value
>> 
>> where `print-attribute` is the java print attribute, `print-attribute-value` is the corresponding attribute value, and `key` and `value` is the key/value pair used by a specific printer.
>> 
>> For example, for `Chromaticity` attribute the property file could look like:
>> 
>> Chromaticity.MONOCHROME.ColorModel=Gray
>> Chromaticity.COLOR.ColorModel=CMYK
>> Chromaticity.MONOCHROME.HPColorMode=grayscale
>> Chromaticity.COLOR.HPColorMode=color
>> 
>> where `Chromaticity.MO...
>
> Since the user can always select greyscale in the user dialog, I presume you have some requirement
> to do this printing without user intervention. Perhaps there's no user there (server-side printing), or
> the app would like to make sure the user always defaults to B&W.
> 
> As far as I can tell, this isn't supported via any kind of API on macOS, so it is not a Java problem.
> You could be printing from an Objective-C app written directly to Cocoa APIs and still have the same problem.
> So a Java-specific workaround like this seems inappropriate.
> 
> I've poked around to help me understand what is going on.
> 
> When I do "Print to File" on macOS - meaning use the native printer dialog's "Save as PDF" option,
> then the generated PDF is always colour even if I select the printer dialog's "Grayscale Printing" option.
> This isn't just true for Java apps, the same happens if I print a web page from Safari.
> 
> And when I query the  Chromaticity support for a couple of colour printers - one Canon, one HP,
> both report they support it but only the value COLOR.
> 
> So I conclude the grayscale printing option is something handled by the printer driver at the time it is converted to
> the printer-specific format and sent to the physical printer and it isn't changing the rendering.
> 
> So in general without an API, to get greyscale it requires the end-user to set an option in a print dialog
> and as mentioned above, what you are trying  o enable isn't possible even if you wrote the app in
> Objective-C or Swift directly as a macOS native app.
> 
> But what works for me to get greyscale by default is to set that up as the default for the print queue.
> It is easy to add a printer twice - with two queues for it.
> One has the default set to greyscale, the other to colour. Then the app just needs to select the required queue.
> This is clearly more site-specific than having the app just specify MONOCHROME but is a lot lower cost all round.
> 
> I don't understand why PMSetColorMode is deprecated and non-functional since it seems like it would
> be the right option here, but then internally macOS would need to be able to map it to the right option.
> Doubtless that would be easier if MONOCHROME were supported by all these drivers and I don't understand
> that omission either. In fact if it were we probably could just specify that directly without macOS needing
> to understand anything - like  I expect it doesn't understand the key/value pairs your code is sending it.
> I note that you send ALL known key/value pairs and hope one ...

> @prrace thanks for the detailed thoughts on this problem. As the stakeholder in this issue, I wanted to offer some feedback to your thoughts. I understand that the desire for OpenJDK is to NOT maintain a list of proprietary printer settings, but since many of the thoughts above get into use-case scenarios, I feel compelled to share my perspective. I hope these are well received.
> 
> > When I do "Print to File" on macOS - meaning use the native printer dialog's "Save as PDF" option,
> > then the generated PDF is always colour even if I select the printer dialog's "Grayscale Printing" option.
> > This isn't just true for Java apps, the same happens if I print a web page from Safari.
> 
> Several PDF printers (on several OSs) ignore grayscale/b&w settings. I'm not sure why, but I've observed the same.
> 
> > As far as I can tell, this isn't supported via any kind of API on macOS, so it is not a Java problem.
> > You could be printing from an Objective-C app written directly to Cocoa APIs and still have the same problem.
> 
> Agreed.
> 
> > So a Java-specific workaround like this seems inappropriate.
> 
> As the stakeholder (biased) it's hard for me to agree, however allowing the implementing application to maintain (and thus offer) this workaround would certainly suffice. Since AWT (quite graciously) abstracts these attributes away from the user, "wontfix" status naturally causes a feature gap, albeit not the fault of OpenJDK, but a parity that -- at a bare minimum -- could live on as -- for example -- a workaround on Stackoverflow, etc.
> 
> > But what works for me to get greyscale by default is to set that up as the default for the print queue.
> > It is easy to add a printer twice - with two queues for it.
> 
> Easy is subjective (and prescriptive). Again, biased, but setting up additional printer queues is a viable workaround, but comes at a factor of 2 queues for each color printer added to a system. This also offers support redundancies when removing and re-adding a printer (e.g. IP, port or driver change).
> 
> > I don't understand why `PMSetColorMode` is deprecated and non-functional since it seems like it would
> > be the right option here, but then internally macOS would need to be able to map it to the right option.
> 
> Agreed.
> 
> > [...] all it takes is some vendor API change or a different printer and it just won't work again.
> > These points and the implied maintenance cost are some of my bigger concerns with this.
> 
> Understood.
> 
> > The other idea that crossed my mind is that instead of relying on a printing solution, we could
> > explicitly render in greyscale. Then we could always declare MONOCHROME support and just emulate it.
> > But I am not sure if this is really possible - it would require changes to the rendering code and
> > I'm not sure if or how if we'd be able to do that properly and safely. And the risks of that clearly extend beyond printing.
> 
> Since printers can emulate grayscale using color cartridges, I do not believe this will yield the same results as expected on all printers, but I do believe this to be a creative stop-gap/workaround which may be suitable for some use-cases. Naturally, I would expect some performance implications as a result. As the stakeholder, I can say that this will be trickier with prints using vector graphics than those already rastered/pixels. Speculating, vector graphics will likely be less performance-affecting, but require diving into the document modifications (e.g. PDFBOX, JavaFX) albeit more performant, will require some creative code to desaturate all color data in all objects prior to sending (or requests to add APIs thereo to each specific project).
> 
> > Perhaps there's no user there (server-side printing), or the app would like to make sure the user always defaults to B&W.
> 
> I'm not sure how much interest there is in understanding the use-case that discovered this issue, but it's part of a (pretty popular) Java app that helps print documents. It does so through a WebSocket interface... so in that sense it is server-like (effectively headless), although it's predominantly used by ordinary, non-technical end-users and runs as a sort of background service. Much like AWT offers a (rather) standardized API for printing, so does the Websocket interface, so "Black & White" or "Monochrome" are offered as common, selectable options. "Always default to B&W" would be a case-by-case situation, depending on how the websocket API is offered up (e.g. web app) to the end-user.

Use cases are always interesting.

The idea about changing our rendering to be greyscale would be easier if the printing API explicitly supported it.
It could be quite challenging and risky to actually do it otherwise, so it is just an idea.

Windows/GDI printing lets you set whether you want color or not with a standard field in the struct which controls printing
https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-devmodew
SFAIK that isn't using some driver-specific way of rendering and it seems to work fine.

Although I've yet to find any evidence of it being available, it is possible that printers using IPP on macOS
will support print-color-mode as documented here :  https://www.pwg.org/ipp/ippguide.html
If that becomes standard and widely available it would be a better way to do this.
But I need to understand it better, which would start with finding *anything* that supports it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18195#issuecomment-2062236965

From honkar at openjdk.org  Thu Apr 18 00:58:07 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 18 Apr 2024 00:58:07 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v8]
In-Reply-To: <V1NMUh460PcWjvbl83QcEdb99Dqy6MRABi9-eQao1M8=.8f4aa003-f8e3-4aa6-90e1-64eb6a6475a2@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <V1NMUh460PcWjvbl83QcEdb99Dqy6MRABi9-eQao1M8=.8f4aa003-f8e3-4aa6-90e1-64eb6a6475a2@github.com>
Message-ID: <lnaJsQnE4KwwawmD-1bW7YhjgxLCaFJPG9ZWErFX3Qw=.26580525-c4c8-46df-a065-c62c5634555d@github.com>

On Wed, 10 Apr 2024 05:25:37 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tabs Opaque checkbox handle in synth derived lafs

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 152:

> 150: 
> 151:         layoutButtonPanel.add(scrollButton);
> 152:         layoutButtonPanel.add(wrapButton);

Unless the test frame is resized or there are more number of tabs, the effect of `SCROLL_TAB_LAYOUT` or `WRAP_TAB_LAYOUT` isn't seen.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1569742062

From tr at openjdk.org  Thu Apr 18 04:08:56 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 18 Apr 2024 04:08:56 GMT
Subject: RFR: 8328896: Fontmetrics for large Fonts has zero width
In-Reply-To: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
References: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
Message-ID: <0jC30BKR9FVRAybA2i6_UNn3xJorWh-PFkroWJJDYPM=.5f134531-8c4a-4436-863e-a1b58bb58019@github.com>

On Tue, 9 Apr 2024 18:50:17 GMT, Phil Race <prr at openjdk.org> wrote:

> The main problem here is that we do not curate what font point size we passed to freetype,
> and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
> This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
> But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
> values, so 32767 is really the max.
> But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
> And we can request bigger sizes than that by making use of the transform.
> At normal size ranges we use that just to account for rotation and decompose the glyph transform
> into point size and that rotation.
> 
> But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
> from not specifying the target point size. So we can extend the range of sizes we allow.
> 
> If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
> a for a NaN transform.
> 
> These extreme values aren't useful.
> 
> In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
> for rendering. Which is not useful and could lead to inconsistent results. I fixed that.
> 
> Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.
> 
> The test is mainly around making sure that "sensible" things are returned for not sensible input.
> There's no 100% right answer to these extreme unrenderable sizes.

Can you please update the copywrite year for updated files.

src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 537:

> 535:     if (TOO_LARGE(dmat[0], ptsz) || TOO_LARGE(dmat[1], ptsz) ||
> 536:         TOO_LARGE(dmat[2], ptsz) || TOO_LARGE(dmat[3], ptsz))
> 537:     {

Suggestion:

     TOO_LARGE(dmat[2], ptsz) || TOO_LARGE(dmat[3], ptsz)) {

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

PR Review: https://git.openjdk.org/jdk/pull/18703#pullrequestreview-2007782870
PR Review Comment: https://git.openjdk.org/jdk/pull/18703#discussion_r1569913489

From abhiscxk at openjdk.org  Thu Apr 18 04:47:15 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 18 Apr 2024 04:47:15 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v9]
In-Reply-To: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
Message-ID: <f5WU1WF0EMqUeLpo3WCfA_4ef5DN12w1fXcnwpOklUo=.653ea83b-178e-42bc-b621-7404fb96c720@github.com>

> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
> 
> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
> 
> CI link is posted in JBS.

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

  Number of tab increased

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17720/files
  - new: https://git.openjdk.org/jdk/pull/17720/files/066b5fd6..b99a1819

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

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

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

From abhiscxk at openjdk.org  Thu Apr 18 04:47:15 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 18 Apr 2024 04:47:15 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v8]
In-Reply-To: <lnaJsQnE4KwwawmD-1bW7YhjgxLCaFJPG9ZWErFX3Qw=.26580525-c4c8-46df-a065-c62c5634555d@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <V1NMUh460PcWjvbl83QcEdb99Dqy6MRABi9-eQao1M8=.8f4aa003-f8e3-4aa6-90e1-64eb6a6475a2@github.com>
 <lnaJsQnE4KwwawmD-1bW7YhjgxLCaFJPG9ZWErFX3Qw=.26580525-c4c8-46df-a065-c62c5634555d@github.com>
Message-ID: <4CgLh6pTvDRT2fw6XbrZNGZpY4SIw5PFgQFN5OZG2y4=.da33f02a-93f4-4da8-88b2-be03e2d512fa@github.com>

On Thu, 18 Apr 2024 00:55:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tabs Opaque checkbox handle in synth derived lafs
>
> test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 152:
> 
>> 150: 
>> 151:         layoutButtonPanel.add(scrollButton);
>> 152:         layoutButtonPanel.add(wrapButton);
> 
> Unless the test frame is resized or there are more number of tabs, the effect of `SCROLL_TAB_LAYOUT` or `WRAP_TAB_LAYOUT` isn't seen.

Updated the number of test to have the effect of `SCROLL_TAB_LAYOUT` or `WRAP_TAB_LAYOUT`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1569962076

From tr at openjdk.org  Thu Apr 18 05:09:55 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 18 Apr 2024 05:09:55 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled
In-Reply-To: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
Message-ID: <4qNUR1fWnPTXvUPiIg74TyvyK4kxJiFThLoM_VzZUyY=.3d627cd3-6cdc-4218-880c-ec6913f9b1ca@github.com>

On Mon, 8 Apr 2024 06:09:16 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
> 
> Regards,
> Renjith.

Since the changes/restructuring is more, it would be better to add more details in description which would help in review process.

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

PR Review: https://git.openjdk.org/jdk/pull/18670#pullrequestreview-2007857692

From jwaters at openjdk.org  Thu Apr 18 05:33:05 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 18 Apr 2024 05:33:05 GMT
Subject: RFR: 8330107: Separate out "awt" libraries from Awt2dLibraries.gmk
 [v3]
In-Reply-To: <UdOnik03ALxt-68N4W8L75731jDo0rRv9pB0IE1sksM=.c6265d54-5103-403f-9f93-2f21bc1c5bba@github.com>
References: <zY6uAEb8NEAb-xHFj2uUUZBAfu_-M3mqC8rucMagYNU=.f43d05c0-11c3-4a3b-bcb3-b516b4fcec68@github.com>
 <l_uootPezCJy_laJwlVq9be4vhr3_gXwczS6asUJ6AY=.2aea9697-6099-4983-8469-9e1176dcf110@github.com>
 <UdOnik03ALxt-68N4W8L75731jDo0rRv9pB0IE1sksM=.c6265d54-5103-403f-9f93-2f21bc1c5bba@github.com>
Message-ID: <Kc8YmdZSP0mD9WjRDNFtrcplcDPUyHNaASeeocwQ31o=.270bda31-dd48-4014-996b-d0f55d53e9c4@github.com>

On Tue, 16 Apr 2024 18:34:49 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There is no good IDE support for Makefiles, especially not with the level of customization that we have done to make. I am positively struggling with navigating this file, time and time again.

I find Eclipse CDT to be rather helpful with Makefile syntax highlighting, if that helps. Just have to set the .gmk extension to be recognized as a Makefile, and then you should be good to go

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

PR Comment: https://git.openjdk.org/jdk/pull/18743#issuecomment-2063032309

From abhiscxk at openjdk.org  Thu Apr 18 06:00:58 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 18 Apr 2024 06:00:58 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <4Tqn_NILqWAu_5WY0oKDytmi7vQ69zWwEwKv0I9vdvs=.9b28b2a9-aabc-414e-b524-f19e91f2d6a3@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <4Tqn_NILqWAu_5WY0oKDytmi7vQ69zWwEwKv0I9vdvs=.9b28b2a9-aabc-414e-b524-f19e91f2d6a3@github.com>
Message-ID: <jeixfOlx8O2Q-fGAYxv8p6cvAUExyFL4NBYrnC2kfuE=.1c97a12c-9f6b-4232-a6e3-6388549f223c@github.com>

On Tue, 16 Apr 2024 07:13:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment update, tolerance check removed
>
> As far as I understand the test creates two enabled-JComboBox, then disables both, and then compares the disabled and enabled images. Why there are some differences in sizes and colors?

@mrserb Do you have any other suggestion ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18644#issuecomment-2063058580

From serb at openjdk.org  Thu Apr 18 08:10:58 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 18 Apr 2024 08:10:58 GMT
Subject: RFR: 8289770: Remove Windows version macro from ShellFolder2.cpp
In-Reply-To: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
Message-ID: <OgkBnWNOKXRccIDvFEJtz8PDTFguXnPwVaWWcBahCVg=.fb5bd5a0-5aed-49c7-9c8a-b3ae148457a0@github.com>

On Thu, 11 Apr 2024 09:33:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
> 
> `IS_WINVISTA` was not used at all.
> 
> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18736#pullrequestreview-2008154224

From pminborg at openjdk.org  Thu Apr 18 11:32:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 18 Apr 2024 11:32:13 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

  Change exception type

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/2ebac9fc..e2f6c4c9

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

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

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

From jvernee at openjdk.org  Thu Apr 18 12:21:58 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 18 Apr 2024 12:21:58 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
Message-ID: <ftS-TAS4lTtUvayLC83NpNpioHhv2W3ohZMkPKyAydY=.8d2decb3-19ed-4795-89b5-c1a44183a947@github.com>

On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception type

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2008729407

From rkannathpari at openjdk.org  Thu Apr 18 13:35:01 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 18 Apr 2024 13:35:01 GMT
Subject: Integrated: 8329322 : Convert PageFormat/Orient.java to use
 PassFailJFrame
In-Reply-To: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
References: <4VsITw0w48xKHF4D13adFUbiPv-SJldJjeO0cK-tAZE=.358e20dd-ebb0-4753-a0ef-157a12c4a994@github.com>
Message-ID: <1fcyxG3N5jAQanFfBTZyVnAN_CcJJ5VZgrk1jjp8o50=.4484d3db-6f39-41b5-85b1-8c7689e1739f@github.com>

On Thu, 4 Apr 2024 12:07:46 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> I have updated the test with PassFailJFrame along with printer availability check. Please review and let me know your suggestions.
> 
> Renjith.

This pull request has now been integrated.

Changeset: f713766c
Author:    Renjith Kannath Pariyangad <rkannathpari at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f713766cab649947e543f0290717e7bcc501f063
Stats:     418 lines in 1 file changed: 19 ins; 355 del; 44 mod

8329322: Convert PageFormat/Orient.java to use PassFailJFrame

Reviewed-by: abhiscxk, aivanov

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

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

From aivanov at openjdk.org  Thu Apr 18 15:21:56 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 18 Apr 2024 15:21:56 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled
In-Reply-To: <4qNUR1fWnPTXvUPiIg74TyvyK4kxJiFThLoM_VzZUyY=.3d627cd3-6cdc-4218-880c-ec6913f9b1ca@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <4qNUR1fWnPTXvUPiIg74TyvyK4kxJiFThLoM_VzZUyY=.3d627cd3-6cdc-4218-880c-ec6913f9b1ca@github.com>
Message-ID: <8R4B2afEBBtwQpkIJTQ0ZX9aH_IubVcP_bZqH32p7IU=.2b8787d3-e836-4f95-872f-172a672049c0@github.com>

On Thu, 18 Apr 2024 05:07:04 GMT, Tejesh R <tr at openjdk.org> wrote:

> Since the changes/restructuring is more, it would be better to add more details in description which would help in review process.

What details are you looking for?

The purpose of the changes hasn't changed: make the code thread-safe in regards to managing `pageLoader`.

The changes make the code thread safe. Restructuring makes the intent clearer; eliminating long else branches is always a good thing.

Then another part of the handling which was at the very bottom of the method is moved upwards because it is relevant only if the base URL didn't change.

I haven't looked thoroughly at all the cases, yet the updated method looks better in my opinion. There could still be things to improve.

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

PR Comment: https://git.openjdk.org/jdk/pull/18670#issuecomment-2064200198

From dnguyen at openjdk.org  Thu Apr 18 15:55:59 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 18 Apr 2024 15:55:59 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v4]
In-Reply-To: <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
Message-ID: <jrmrqrweMbm3jivJw8YSzxrZYvcfrhbWI4klMURCwhU=.362869ed-77d3-485d-b604-5be09d98530c@github.com>

On Wed, 17 Apr 2024 04:31:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   testDir moved to method

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-2009296911

From dnguyen at openjdk.org  Thu Apr 18 15:56:00 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 18 Apr 2024 15:56:00 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v3]
In-Reply-To: <_6nFlCFX8bHDS94eor1fCKQW38z5zpA5BqKU40JeIoY=.dc5b576f-9f2e-4785-9d52-f6ddbec782f7@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <jOq7RLQHZ--jpCM35leDFsEEa9WX0vgFl8u5SgRSpFs=.97a8edc6-d0ee-4a28-8e00-48a61cc42d06@github.com>
 <4Tqn_NILqWAu_5WY0oKDytmi7vQ69zWwEwKv0I9vdvs=.9b28b2a9-aabc-414e-b524-f19e91f2d6a3@github.com>
 <r9dp9WNO_rvvJ4TZ_AMx-RDe4tC48f0lO5CDRdZTpbI=.e25bbb88-9dd0-4d67-9927-5e14f7f16cb4@github.com>
 <_6nFlCFX8bHDS94eor1fCKQW38z5zpA5BqKU40JeIoY=.dc5b576f-9f2e-4785-9d52-f6ddbec782f7@github.com>
Message-ID: <3D4Dtu8lVea5rShSr5eicBeETGtnuVPNyexUmPFJnj4=.98795337-a7ca-48d2-834a-83ef18718b5d@github.com>

On Wed, 17 Apr 2024 09:55:43 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > As far as I understand the test creates two enabled-JComboBox, then disables both, and then compares the disabled and enabled images. Why there are some differences in sizes and colors?
> 
> Difference in size is specific to LAFs like in case on Metal and Motif the sizes are same but in Nimbus and GTK it differs in size. For Nimbus when DefaultListCellRenderer is used the width is 2px more than when SynthComboBoxRenderer is used. This is due to the difference in Inset values. In case of DefaultListCellRenderer the Insets value (left and right) are 1 px more than the insets value for SynthComboBoxRenderer.
> 
> Similarly in GTK LAF also the insets values are different in DefaultListCellRenderer and SynthComboBoxRenderer.
> 
> Color difference is only in the background color for Windows LAF which is slightly different.

This sounds about right. I looked into this difference briefly in my original fix, and checked the insets, bounds, and borders. Now that you mention it, I remember it was the insets that differed between the two renderers. Didn't seem related to the issue/fix and may be intended, so I left it as is and modified my test to use a midline scan to compare the pixel colors between the two comboboxes.

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

PR Comment: https://git.openjdk.org/jdk/pull/18644#issuecomment-2064335397

From serb at openjdk.org  Thu Apr 18 16:52:04 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 18 Apr 2024 16:52:04 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v4]
In-Reply-To: <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
Message-ID: <fB3rMZo-HmSST8_wxTmPIathEq13E-qJW88tj79jvmg=.51a9c996-9eaf-405a-8ab1-b12cca5fc2d8@github.com>

On Wed, 17 Apr 2024 04:31:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   testDir moved to method

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-2009415330

From aivanov at openjdk.org  Thu Apr 18 17:05:01 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 18 Apr 2024 17:05:01 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled
In-Reply-To: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
Message-ID: <Hajy-gCOLcE6kFAVLeDJXGaH4SRv3vlALX0XR0kpy2E=.93947292-0862-4ca8-a916-f1529a4f6dd9@github.com>

On Mon, 8 Apr 2024 06:09:16 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
> 
> Regards,
> Renjith.

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 485:

> 483:         Object postData = getPostData();
> 484:         if ((loaded == null) || !loaded.sameFile(page) || (postData != null)) {
> 485:             // different url or POST method, load the new content

Here's a mistake: if `postData != null`, we should proceed with the request. Thus, the condition in the `if`-block which verifies if the page needs reloading should also have this condition added.

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 486:

> 484:             }
> 485:             return;
> 486:         }

This code should be moved above the previous `if`-block. Using `page.sameFile(loaded)` avoids the null-check.

Then if `page.getRef()` is `null`, I think we should still move the scrolling to start of the viewport as it's done in the `if`-block above.

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 491:

> 489:         if ((postData == null) && (kit == null)) {
> 490:             return;
> 491:         }

This is another mistake, the editor kit changes when `getStream` method is called. Therefore, the condition to check `if (kit == null)` should be moved below line 513 where `getStream` is called.

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 497:

> 495:             // we need to cancel background loading
> 496:             if (pageLoader != null) {
> 497:                 pageLoader.cancel(true);

Suggestion:

                pageLoader.cancel(true);
                pageLoader = null;

Let's assign `null` to indicate there's no active `pageLoader` any more.

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 532:

> 530:         }
> 531:         read(in, doc);
> 532:         setDocument(doc);

Suggestion:

        }

        read(in, doc);
        setDocument(doc);

I recommend adding a blank line here to emphasise the separation: the body `if` never returns.

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

PR Review: https://git.openjdk.org/jdk/pull/18670#pullrequestreview-2009370111
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1571061414
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1571057721
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1571064475
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1571077133
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1571075519

From prr at openjdk.org  Thu Apr 18 17:27:56 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 18 Apr 2024 17:27:56 GMT
Subject: RFR: 8328896: Fontmetrics for large Fonts has zero width
In-Reply-To: <0jC30BKR9FVRAybA2i6_UNn3xJorWh-PFkroWJJDYPM=.5f134531-8c4a-4436-863e-a1b58bb58019@github.com>
References: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
 <0jC30BKR9FVRAybA2i6_UNn3xJorWh-PFkroWJJDYPM=.5f134531-8c4a-4436-863e-a1b58bb58019@github.com>
Message-ID: <D-rLWSQF6wQXlSLpr1JX7u6H9WXR_9DnM3eY-wzUbXw=.e9ec7e83-2f75-4c0e-9c0b-fe02ea011a9f@github.com>

On Thu, 18 Apr 2024 04:03:38 GMT, Tejesh R <tr at openjdk.org> wrote:

>> The main problem here is that we do not curate what font point size we passed to freetype,
>> and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
>> This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
>> But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
>> values, so 32767 is really the max.
>> But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
>> And we can request bigger sizes than that by making use of the transform.
>> At normal size ranges we use that just to account for rotation and decompose the glyph transform
>> into point size and that rotation.
>> 
>> But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
>> from not specifying the target point size. So we can extend the range of sizes we allow.
>> 
>> If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
>> a for a NaN transform.
>> 
>> These extreme values aren't useful.
>> 
>> In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
>> for rendering. Which is not useful and could lead to inconsistent results. I fixed that.
>> 
>> Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.
>> 
>> The test is mainly around making sure that "sensible" things are returned for not sensible input.
>> There's no 100% right answer to these extreme unrenderable sizes.
>
> src/java.desktop/share/native/libfontmanager/freetypeScaler.c line 537:
> 
>> 535:     if (TOO_LARGE(dmat[0], ptsz) || TOO_LARGE(dmat[1], ptsz) ||
>> 536:         TOO_LARGE(dmat[2], ptsz) || TOO_LARGE(dmat[3], ptsz))
>> 537:     {
> 
> Suggestion:
> 
>      TOO_LARGE(dmat[2], ptsz) || TOO_LARGE(dmat[3], ptsz)) {

No, that was deliberate. We generally prefer the { on a new line if the conditional is multi-line.

Still looking for an actual "reviewer" review here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18703#discussion_r1571126135

From mcimadamore at openjdk.org  Thu Apr 18 17:35:04 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 Apr 2024 17:35:04 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
Message-ID: <UDD_yQgZ0kLqCklBpSu6Q-uIXxfH7Du9VrFCOWtsbVU=.76d48499-8973-433e-8684-1dcec989d154@github.com>

On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception type

We need a test for the new method, e.g. to check that the right exception is thrown, and the message is right. The fact that no test needed to be updated when you changed the exception type is a smell.

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

Changes requested by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2009500390

From prr at openjdk.org  Thu Apr 18 18:02:57 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 18 Apr 2024 18:02:57 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v6]
In-Reply-To: <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <2FFaFRgutA2t8ufmdNJUHF1N02EEQeIyt_4wj8qCYn4=.079b00e1-e4c5-4f78-9b91-0633426191a7@github.com>
Message-ID: <TwcBMY5juNZRirnFrvCpsIhPdKl28QKyc_RV2eHuZZo=.25b492f9-ee3d-49ca-bbfe-d85d299c106e@github.com>

On Thu, 18 Apr 2024 11:32:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change exception type

I'm OK with the minimal changes in the desktop code.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18474#pullrequestreview-2009552015

From vdyakov at openjdk.org  Thu Apr 18 18:15:57 2024
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Thu, 18 Apr 2024 18:15:57 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <B_Y7vyiHi6Zlj2YSkPAsux4wL-z3lFdZB6QWR7oyuV8=.26a16963-9cbf-4dd9-a7d5-417e8469c5e6@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

@honkar-jdk could you please review?

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2064811815

From honkar at openjdk.org  Thu Apr 18 20:46:55 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 18 Apr 2024 20:46:55 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <d4SOTSersooNxNNC3Dd0QJBKyrBKdw9xh0I4ICKqpOw=.f93efbb1-dd97-4c32-b8d9-2c88ea02dacd@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

@TejeshR13 
Based on the PR description the source code fix looks correct. 
I was unable to test it on my local Win machine due to printer issues. The Print to PDF option isn't working too. But this is something to do with my system config and not related to the fix.
Since I wasn't able to test it completely, would like another reviewer to go through it.

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18706#pullrequestreview-2009854469

From jjg at openjdk.org  Thu Apr 18 20:48:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:48:04 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`
Message-ID: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>

Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.

There are various categories of update:

* "Box comments" beginning with `/**`
* Misplaced doc comments before package or import statements
* Misplaced doc comments after the annotations for a declaration
* Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
* Use of `/**` for the legal header at or near the top of the file

In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

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

Commit messages:
 - JDK-8330178: Clean up non-standard use of /** comments in `java.base`

Changes: https://git.openjdk.org/jdk/pull/18846/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330178
  Stats: 134 lines in 23 files changed: 50 ins; 56 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/18846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18846/head:pull/18846

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

From honkar at openjdk.org  Thu Apr 18 20:49:56 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 18 Apr 2024 20:49:56 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <a4Sc5UVHubTg53HlvyFkOB2dd29H0cOsIkFEMjVhDOk=.251d96ee-e033-4f6d-bb6e-6fa8e0d3260a@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

/Reviewers 2

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2065295609

From jjg at openjdk.org  Thu Apr 18 20:52:29 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:52:29 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v4]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <p1Ldsyr_hNrd7LEhoThBxZzXEtMZk3siO_ZLFZp43vY=.c61e1870-2db1-4ee8-b157-f6f2b0be1715@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/3f745431..f3670e7a

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

  Stats: 42074 lines in 1058 files changed: 18282 ins; 15937 del; 7855 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From honkar at openjdk.org  Thu Apr 18 20:59:56 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 18 Apr 2024 20:59:56 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <IBA0RYUdpP8cyS4YzB4F3H61jD_jYtd4pRbcDwan_uA=.0054f976-c25a-4d72-b189-f33670108358@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

/Reviewers 2

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2065311286

From mpowers at openjdk.org  Thu Apr 18 21:19:56 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 18 Apr 2024 21:19:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <dmHUQtRTvpmJO4yhZvDJFjFCxtZMXJcJb45ZQ-Lxdlw=.00c6c3b8-960f-4ddb-bb32-0848fc1bad83@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Should the copyright be updated?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2065339389

From jjg at openjdk.org  Thu Apr 18 21:34:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:34:13 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v5]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <Pw-vAt9fBf-s7YcdBbtzbYdcM49PkNcmvIfbSmYdjYI=.a94e6477-30de-463b-b509-d4cd38f26cd7@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  update test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/f3670e7a..8ad8b818

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

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

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

From jjg at openjdk.org  Thu Apr 18 21:56:16 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 21:56:16 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v6]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <_EMQ8vgc0hQdgeWdnqirLLAN8Cj6jcxP0belwJffD8A=.2c536c2b-f0e1-49b4-8fc7-e3a9252e20e2@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=05
  Stats: 488 lines in 61 files changed: 389 ins; 3 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From darcy at openjdk.org  Thu Apr 18 22:50:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Apr 2024 22:50:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <CCg0siue0vsMT0R1LJ9Qgr5BN7eORlS-sqNih3qh2Tg=.8df332ee-d15a-4678-8bbd-9baf26c0e257@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010059355

From iris at openjdk.org  Thu Apr 18 22:59:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Apr 2024 22:59:55 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <0ffUuhd3mqnGetQ_dn60M7NrftiL02UD7zbITanAuJc=.b4ac0b9d-01c0-47be-a315-903e9ed6424f@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010068091

From honkar at openjdk.org  Thu Apr 18 23:27:56 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 18 Apr 2024 23:27:56 GMT
Subject: RFR: 8329559: Test javax/swing/JFrame/bug4419914.java failed
 because The End and Start buttons are not placed correctly and Tab focus does
 not move as expected [v2]
In-Reply-To: <D1KA3JdD9qQ4HW5IOrXIpw_B22yxJGegx55Nj4tZsJ0=.2e4709c4-8b18-412f-82be-a2cf92df188e@github.com>
References: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>
 <D1KA3JdD9qQ4HW5IOrXIpw_B22yxJGegx55Nj4tZsJ0=.2e4709c4-8b18-412f-82be-a2cf92df188e@github.com>
Message-ID: <EF0TqpGoXiFa4VEeDwpqI9yZMFcfapUFhkUG4z_ej14=.e8a8d5c2-f60c-42af-9812-a67409efdddf@github.com>

On Thu, 4 Apr 2024 09:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test issue shows the End and Start buttons are not placed as per instructions due to ComponentOrientation RTL was not honoured, as with `getContentPane()` being removed from `add` call of JFrame, it was also additionally removed from other JFrame calls which resulted in the RTL not being propagated to its child. Fix is to add `getContentPane()` to the non-add methods of JFrame as was done in the applet version of the test..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   instruction formatting

LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18612#pullrequestreview-2010095658

From honkar at openjdk.org  Fri Apr 19 00:56:58 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 19 Apr 2024 00:56:58 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v9]
In-Reply-To: <f5WU1WF0EMqUeLpo3WCfA_4ef5DN12w1fXcnwpOklUo=.653ea83b-178e-42bc-b621-7404fb96c720@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <f5WU1WF0EMqUeLpo3WCfA_4ef5DN12w1fXcnwpOklUo=.653ea83b-178e-42bc-b621-7404fb96c720@github.com>
Message-ID: <lSIFbJ-QkI6sUgL6svobMeJDI-xik57aptidC4fGGDg=.318f80b3-0d0e-4775-9eb0-d80747bb0341@github.com>

On Thu, 18 Apr 2024 04:47:15 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Number of tab increased

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 83:

> 81:               - Select the 'content opaque' and check that content area is opaque
> 82:                 (it must be gray).
> 83:             Check this behaviour for other LAFs and tab layout.

@kumarabhi006 Click to check box 'content opaque' might seem unclear, whether the checkbox needs to be checked or unchecked. It is better to replace it with phrases - "checked/unchecked" or "select/unselect" as below.

Same applies to Case 1 and Case 3.


Test Case 2 - Test Content pane opacity:
To test Content pane opacity, make sure "Opaque checkbox" is UNCHECKED.

Verify the following with 'content opaque' option:
- when checked: the content area should be opaque (it must be gray).
- when unchecked: the content area should be transparent (it must be green).
           
Check this behavior for other LAFs and tab layout.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1571572910

From honkar at openjdk.org  Fri Apr 19 01:00:57 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 19 Apr 2024 01:00:57 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v9]
In-Reply-To: <f5WU1WF0EMqUeLpo3WCfA_4ef5DN12w1fXcnwpOklUo=.653ea83b-178e-42bc-b621-7404fb96c720@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <f5WU1WF0EMqUeLpo3WCfA_4ef5DN12w1fXcnwpOklUo=.653ea83b-178e-42bc-b621-7404fb96c720@github.com>
Message-ID: <t_1nZivyPn6LU82JEDr6ViESFXU7EofjMccnMeg9758=.79c7dab8-914b-43eb-b6f5-0158f52befba@github.com>

On Thu, 18 Apr 2024 04:47:15 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Number of tab increased

Tested on Ubuntu, changes look good.

Minor:
Test instructions can be rephrased for clarity.
Copyright years need to be updated for some of source code files.

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17720#pullrequestreview-2010302976

From jdv at openjdk.org  Fri Apr 19 04:58:58 2024
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 19 Apr 2024 04:58:58 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v4]
In-Reply-To: <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
 <6SqbkjJ75o79tCzOcYMGvddfQnqvmMa-ON5W_gjvW6A=.a1ea1ca5-1715-404f-a00f-b7f3934afa7c@github.com>
Message-ID: <PRAz3epVyuXx0i7FtExngUAhI6Wud_GHr9IcYfpWJnY=.c1db9ff7-e8e4-4335-b25d-b1d9818f26f7@github.com>

On Wed, 17 Apr 2024 04:31:16 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
>> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
>> 
>> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
>> 
>> CI testing is green for the modified test. Link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   testDir moved to method

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18644#pullrequestreview-2010528135

From tr at openjdk.org  Fri Apr 19 05:09:58 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 19 Apr 2024 05:09:58 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <d4SOTSersooNxNNC3Dd0QJBKyrBKdw9xh0I4ICKqpOw=.f93efbb1-dd97-4c32-b8d9-2c88ea02dacd@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <d4SOTSersooNxNNC3Dd0QJBKyrBKdw9xh0I4ICKqpOw=.f93efbb1-dd97-4c32-b8d9-2c88ea02dacd@github.com>
Message-ID: <zE0Uj8fxxfhO95uifOTtqVGMBIXvdh_RFSc5HunX8tQ=.89be1852-57cd-4f8d-a940-d6442ea10fa1@github.com>

On Thu, 18 Apr 2024 20:44:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> @TejeshR13 Based on the PR description the source code fix looks correct. I was unable to test it on my local Win machine due to printer issues. The Print to PDF option isn't working too. But this is something to do with my system config and not related to the fix. Since I wasn't able to test it completely, would like another reviewer to go through it.

In that case I guess you can test print to pdf using "print to file" checkbox which shows in print dialog, don't have to change the printer name in combobox (I do this in linux).

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2065771721

From abhiscxk at openjdk.org  Fri Apr 19 05:10:15 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 19 Apr 2024 05:10:15 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v10]
In-Reply-To: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
Message-ID: <3cuOLs-Q6ycJrKrRey_ww2YQQemNvaUOx2kwcLmsc9U=.02532e64-f3b0-4ffd-b2db-23f436cb32bf@github.com>

> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
> 
> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
> 
> CI link is posted in JBS.

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

  instruction and copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17720/files
  - new: https://git.openjdk.org/jdk/pull/17720/files/b99a1819..0973b9a4

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

  Stats: 28 lines in 5 files changed: 10 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/17720.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17720/head:pull/17720

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

From abhiscxk at openjdk.org  Fri Apr 19 05:10:15 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 19 Apr 2024 05:10:15 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v9]
In-Reply-To: <t_1nZivyPn6LU82JEDr6ViESFXU7EofjMccnMeg9758=.79c7dab8-914b-43eb-b6f5-0158f52befba@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <f5WU1WF0EMqUeLpo3WCfA_4ef5DN12w1fXcnwpOklUo=.653ea83b-178e-42bc-b621-7404fb96c720@github.com>
 <t_1nZivyPn6LU82JEDr6ViESFXU7EofjMccnMeg9758=.79c7dab8-914b-43eb-b6f5-0158f52befba@github.com>
Message-ID: <rjYLMuyELhl-2wwaqL6Wt_BBhclSNtjBaz_5ufNGuUI=.14df3366-cb15-469f-b6f6-9a94a5ed302b@github.com>

On Fri, 19 Apr 2024 00:58:00 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Tested on Ubuntu, changes look good.
> 
> Minor: Test instructions can be rephrased for clarity. Copyright years need to be updated for some of source code files.

Updated.

> test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 83:
> 
>> 81:               - Select the 'content opaque' and check that content area is opaque
>> 82:                 (it must be gray).
>> 83:             Check this behaviour for other LAFs and tab layout.
> 
> @kumarabhi006 Click to check box 'content opaque' might seem unclear, whether the checkbox needs to be checked or unchecked. It is better to replace it with phrases - "checked/unchecked" or "select/unselect" as below.
> 
> Same applies to Case 1 and Case 3.
> 
> 
> Test Case 2 - Test Content pane opacity:
> To test Content pane opacity, make sure "Opaque checkbox" is UNCHECKED.
> 
> Verify the following with 'content opaque' option:
> - when checked: the content area should be opaque (it must be gray).
> - when unchecked: the content area should be transparent (it must be green).
>            
> Check this behavior for other LAFs and tab layout.

This looks better than before. Updated the instruction.

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

PR Comment: https://git.openjdk.org/jdk/pull/17720#issuecomment-2065771786
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1571800082

From tr at openjdk.org  Fri Apr 19 05:12:57 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 19 Apr 2024 05:12:57 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled
In-Reply-To: <8R4B2afEBBtwQpkIJTQ0ZX9aH_IubVcP_bZqH32p7IU=.2b8787d3-e836-4f95-872f-172a672049c0@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <4qNUR1fWnPTXvUPiIg74TyvyK4kxJiFThLoM_VzZUyY=.3d627cd3-6cdc-4218-880c-ec6913f9b1ca@github.com>
 <8R4B2afEBBtwQpkIJTQ0ZX9aH_IubVcP_bZqH32p7IU=.2b8787d3-e836-4f95-872f-172a672049c0@github.com>
Message-ID: <sVYIM4WqJnndkznMrnz37MJKsg62Oxx4fgaPi7XaFTg=.a622b468-beb1-4b14-b63b-c104a3f18ff0@github.com>

On Thu, 18 Apr 2024 15:18:56 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Since the changes/restructuring is more, it would be better to add more details in description which would help in review process.
> 
> What details are you looking for?
> 
> The purpose of the changes hasn't changed: make the code thread-safe in regards to managing `pageLoader`.
> 
> The changes make the code thread safe. Restructuring makes the intent clearer; eliminating long else branches is always a good thing.
> 
> Then another part of the handling which was at the very bottom of the method is moved upwards because it is relevant only if the base URL didn't change.
> 
> I haven't looked thoroughly at all the cases, yet the updated method looks better in my opinion. There could still be things to improve.

I wasn't able to make out the changes with comparison since restructuring is also done here. Just like you are explaining here would help in understanding the changes for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18670#issuecomment-2065774397

From abhiscxk at openjdk.org  Fri Apr 19 06:59:12 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 19 Apr 2024 06:59:12 GMT
Subject: RFR: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and
 disabled ComboBox does not match in these LAFs: GTK+ [v5]
In-Reply-To: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
Message-ID: <WKLXfXgXbQ0s8XbdPSgycjirKDMMDCZ-V3M9JGnNO38=.e0d780c4-8209-4ddd-a446-bfd8518a56e8@github.com>

> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
> 
> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
> 
> CI testing is green for the modified test. Link attached in JBS.

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

  Empty-Commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18644/files
  - new: https://git.openjdk.org/jdk/pull/18644/files/5e7bcf37..c67ec7e7

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

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

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

From abhiscxk at openjdk.org  Fri Apr 19 10:14:04 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 19 Apr 2024 10:14:04 GMT
Subject: Integrated: 8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled
 and disabled ComboBox does not match in these LAFs: GTK+
In-Reply-To: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
References: <tfbUcZl-HxMKGAdAR_bPJXdFYGF1_jHgztL7f4f6wlg=.02d2ce7f-b301-4fcb-bbd0-2d020e1c8ce2@github.com>
Message-ID: <27mYprgvhSheVYSF4-At8o15aGkygZMuemrqc1m0Gns=.f7e0ee25-8457-44d3-a996-58ba603ae924@github.com>

On Fri, 5 Apr 2024 06:54:46 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Test was failing on GTK and Windows LAF due to pixel color mismatch. Th reason behind this issue was the size of image which is different and that results in incorrect pixel comparison. Fix is to ensure that correct pixel is matched and the pixel color should remain within tolerance. 
> For windows LAF the background color is not an exact match and thus added a TOLERANCE field to check if the RGB difference is within limits.
> 
> `@key headful` added in jtreg tag to ensure that test run for GTK LAF as well which was not the case before as it is mentioned in JBS `It does not fail in mach5 because on linux + headless mode the gtk L&F is not supported.`
> 
> CI testing is green for the modified test. Link attached in JBS.

This pull request has now been integrated.

Changeset: eb60822a
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eb60822a45ecd076484e707b2dd1049ed9d8079b
Stats:     66 lines in 1 file changed: 19 ins; 33 del; 14 mod

8310072: JComboBox/DisabledComboBoxFontTestAuto: Enabled and disabled ComboBox does not match in these LAFs: GTK+

Reviewed-by: dnguyen, jdv, tr, serb

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

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

From tr at openjdk.org  Fri Apr 19 10:15:26 2024
From: tr at openjdk.org (Tejesh R)
Date: Fri, 19 Apr 2024 10:15:26 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
Message-ID: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>

Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
PassFailJFrame.builder is used.

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

Commit messages:
 - Instructions updated w.r.t OS + PassFailJFrame.builder usage

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

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

From aivanov at openjdk.org  Fri Apr 19 10:34:57 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 10:34:57 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled
In-Reply-To: <sVYIM4WqJnndkznMrnz37MJKsg62Oxx4fgaPi7XaFTg=.a622b468-beb1-4b14-b63b-c104a3f18ff0@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <4qNUR1fWnPTXvUPiIg74TyvyK4kxJiFThLoM_VzZUyY=.3d627cd3-6cdc-4218-880c-ec6913f9b1ca@github.com>
 <8R4B2afEBBtwQpkIJTQ0ZX9aH_IubVcP_bZqH32p7IU=.2b8787d3-e836-4f95-872f-172a672049c0@github.com>
 <sVYIM4WqJnndkznMrnz37MJKsg62Oxx4fgaPi7XaFTg=.a622b468-beb1-4b14-b63b-c104a3f18ff0@github.com>
Message-ID: <aiTsTvyncnut-yYJd_bMnS1gXTnXkEUTkwXuariH8XA=.5e6cf488-efc0-40ef-bd3b-c265dbea9f7d@github.com>

On Fri, 19 Apr 2024 05:10:46 GMT, Tejesh R <tr at openjdk.org> wrote:

> I wasn't able to make out the changes with comparison since restructuring is also done here. Just like you are explaining here would help in understanding the changes for review.

Putting all access to `pageLoader` into a `synchronized` block solves the thread-safety problem.

At the same time, we can improve the readability of the method as a whole. Restructuring helps make the intent clearer, at least I'm aiming to do so.

I agree looking at the diffs here doesn't give you much insight, but going through the original and updated code gives a clearer picture.

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

PR Comment: https://git.openjdk.org/jdk/pull/18670#issuecomment-2066293003

From aivanov at openjdk.org  Fri Apr 19 10:55:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 10:55:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:

> 31: /*
> 32:  * The Apple Security Provider.
> 33:  */

Does it make sense to incorporate this comment into the following javadoc comment?


/**
 * Defines the (an) Apple security provider.
 * ...
 */
@SuppressWarnings("serial") // JDK implementation class

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:

> 35: import static sun.security.util.SecurityProviderConstants.*;
> 36: 
> 37: /*

Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.

The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 38:

> 36: 
> 37: /**
> 38:  * Open an file input stream given a URL.

Suggestion:

 * Open a file input stream given a URL.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572192780
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572184441
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572189001

From aivanov at openjdk.org  Fri Apr 19 11:04:56 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 11:04:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <-ZdPijmlx_H98EC5meigkk-QBEQawMNWEQi-Y-dyHgo=.469f84c6-9897-49c3-ba55-872d13939555@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?


/**
 * This is a class.
 */
public class A {}


or


/**
 * This is a class.
 */

public class A {}


Which is the most common? Which is preferred?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066337900

From dfuchs at openjdk.org  Fri Apr 19 11:29:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 11:29:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <c4-wxoGocaNumdyy8fUX4fVZBsSZxtJcKNmWXGbswiU=.d7e14e40-5057-473b-87af-fae5864be982@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Changes to networking code looks good. I didn't spot any issue with the rest but I'm usually not a reviewer there.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2011186056

From prappo at openjdk.org  Fri Apr 19 11:35:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Apr 2024 11:35:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:

    /**
     * @test TestSmallHeap
     * @bug 8067438 8152239
     * @summary Verify that starting the VM with a small heap works
     * @library /test/lib
     * @modules java.base/jdk.internal.misc
     * @build jdk.test.whitebox.WhiteBox
     * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
     * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
     */

I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066383735

From rkannathpari at openjdk.org  Fri Apr 19 12:30:26 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 19 Apr 2024 12:30:26 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v2]
In-Reply-To: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
Message-ID: <5zD9NbDitMW8NVscRvPJwJ-8jmId7mizpuXpH6dosyA=.83eebfe2-817d-480e-ad2d-cca5a1d82613@github.com>

> Hi Reviewers,
> 
> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
> 
> Regards,
> Renjith.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Suggesions updated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18670/files
  - new: https://git.openjdk.org/jdk/pull/18670/files/fe4b78e0..2ca2ae11

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

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

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

From rkannathpari at openjdk.org  Fri Apr 19 12:30:26 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 19 Apr 2024 12:30:26 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v2]
In-Reply-To: <Hajy-gCOLcE6kFAVLeDJXGaH4SRv3vlALX0XR0kpy2E=.93947292-0862-4ca8-a916-f1529a4f6dd9@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <Hajy-gCOLcE6kFAVLeDJXGaH4SRv3vlALX0XR0kpy2E=.93947292-0862-4ca8-a916-f1529a4f6dd9@github.com>
Message-ID: <24YDZy46jbwiLVSdDMVT5-4l8qeQqlc8ZUt_OQDlFaE=.5c568b12-5b8c-43be-9cd7-c724452f053a@github.com>

On Thu, 18 Apr 2024 16:41:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Suggesions updated
>
> src/java.desktop/share/classes/javax/swing/JEditorPane.java line 497:
> 
>> 495:             // we need to cancel background loading
>> 496:             if (pageLoader != null) {
>> 497:                 pageLoader.cancel(true);
> 
> Suggestion:
> 
>                 pageLoader.cancel(true);
>                 pageLoader = null;
> 
> Let's assign `null` to indicate there's no active `pageLoader` any more.

Updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1572292328

From aivanov at openjdk.org  Fri Apr 19 14:03:00 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 14:03:00 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v2]
In-Reply-To: <5zD9NbDitMW8NVscRvPJwJ-8jmId7mizpuXpH6dosyA=.83eebfe2-817d-480e-ad2d-cca5a1d82613@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <5zD9NbDitMW8NVscRvPJwJ-8jmId7mizpuXpH6dosyA=.83eebfe2-817d-480e-ad2d-cca5a1d82613@github.com>
Message-ID: <othq1L-diDeb_ipo4L5wE2xbzlVEjnER_lmaRP5cEZQ=.2ee661d3-9d13-4a23-b34f-f0c9e8dc6ce3@github.com>

On Fri, 19 Apr 2024 12:30:26 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggesions updated

Changes requested by aivanov (Reviewer).

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 481:

> 479:         if (!page.equals(loaded) && page.getRef() == null) {
> 480:             scrollRectToVisible(new Rectangle(0, 0, 1, 1));
> 481:         }

This should go below the `if`-block:


if ((postData == null) && (page.sameFile(loaded))) {


And the condition becomes redundant. After that `if`-block, we know for sure the page is going to be reloaded. That is the code should look like this:


        if ((postData == null) && (page.sameFile(loaded))) {
            // The same page with different reference
            /* <the code you have> */
            return;
        }

        // different url or POST method, load the new content

        // reset scrollbar
        scrollRectToVisible(new Rectangle(0, 0, 1, 1));

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 488:

> 486:             }
> 487:             return;
> 488:         }

Suggestion:

        if ((postData == null) && (page.sameFile(loaded))) {
            // The same page with different reference
            if (reference != null) {
                scrollToReference(reference);
            } else {
                // Scroll to the top of the page
                scrollRectToVisible(new Rectangle(0, 0, 1, 1));
            }
            return;
        }

Here, `reference` contains the value of `page.getReference()`. I suggest moving that variable to the top too (after `postData`) and re-use it.

I also suggest marking `loaded`, `postData`, `reference` as `final`, it explicitly indicates the values are not changed in the method.

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

PR Review: https://git.openjdk.org/jdk/pull/18670#pullrequestreview-2011492799
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1572416371
PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1572407882

From rkannathpari at openjdk.org  Fri Apr 19 14:53:09 2024
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 19 Apr 2024 14:53:09 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
Message-ID: <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>

> Hi Reviewers,
> 
> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
> 
> Regards,
> Renjith.

Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:

  Rearranged if based on suggesion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18670/files
  - new: https://git.openjdk.org/jdk/pull/18670/files/2ca2ae11..be168e9d

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

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

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

From aivanov at openjdk.org  Fri Apr 19 15:02:59 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 15:02:59 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
Message-ID: <OUDzOs0lEmjRPUF_2W8zLA3Gy-q_FXit1EYRHudg2Gk=.902f90ff-f82c-4bf9-b612-8b9a40167500@github.com>

On Fri, 19 Apr 2024 14:53:09 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearranged if based on suggesion

Looks good to me.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18670#pullrequestreview-2011668563

From asemenov at openjdk.org  Fri Apr 19 15:27:19 2024
From: asemenov at openjdk.org (Artem Semenov)
Date: Fri, 19 Apr 2024 15:27:19 GMT
Subject: RFR: 8323965: modify fix for 8317771 to remove reflection
 instantiation of the inner class
Message-ID: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>

I replaced reflection with using an accessor
@azuev-java please review

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

Commit messages:
 - 8323965 modify fix for 8317771 to remove reflection instantiation of the inner class

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

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

From vdyakov at openjdk.org  Fri Apr 19 16:57:00 2024
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Fri, 19 Apr 2024 16:57:00 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <HVJAplKT-OgftBJBTVkih79CCKlVCv9WwO5XbDPYga8=.75dedca9-82b9-43da-90a2-058585fbd25b@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

@prsadhuk your turn to review

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2066944780

From prr at openjdk.org  Fri Apr 19 17:12:59 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 19 Apr 2024 17:12:59 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <VinHzRZdRVeR711zMh04UDvANeHJWSaIAKpbpoqC9tM=.15580347-a749-46fb-9101-efa50801d284@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

I think @aivanov-jdk and @rajamah should review since they were involved in the fix that caused this and also it means this likely needs backporting.

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2066972154

From jjg at openjdk.org  Fri Apr 19 19:10:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:10:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <ed4aAlPaZnpFM_HVp75esTjXxSCzwKem2HqiWHPwcvM=.8264f272-6ffe-453f-940c-f0db3225adb1@github.com>

On Fri, 19 Apr 2024 10:53:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:
> 
>> 31: /*
>> 32:  * The Apple Security Provider.
>> 33:  */
> 
> Does it make sense to incorporate this comment into the following javadoc comment?
> 
> 
> /**
>  * Defines the (an) Apple security provider.
>  * ...
>  */
> @SuppressWarnings("serial") // JDK implementation class

Maybe, but only maybe, and if so, it would be out of scope for this work. That would be up to the relevant component team.

That being said, neither comment is part of any public API, and this comment is effectively already present in the first sentence of the actual doc comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572813320

From jjg at openjdk.org  Fri Apr 19 19:14:59 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:14:59 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <EyFdhhhVPa0ZjxN9MNwl--5bvRDGYrZJR8miOOgOBZ0=.513db9e4-6a6f-49b2-a0c8-3baa05cf5cf0@github.com>

On Fri, 19 Apr 2024 10:44:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:
> 
>> 35: import static sun.security.util.SecurityProviderConstants.*;
>> 36: 
>> 37: /*
> 
> Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.
> 
> The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

That would be up to the relevant component to decide how to improve these comments. The goal here is proactively fix any warnings that may be generated about multiple doc comments on a declaration.

I note that neither comment contributes to the public API, and that `@author` tags are generally obsolete these days. The VCS metadata is a more accurate reflection of individual contributions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572818078

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

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

  Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
  
  Fix grammatical typo
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18846/files
  - new: https://git.openjdk.org/jdk/pull/18846/files/fcbe02d5..d7b46a85

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

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

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

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

> It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?
> 
> ```java
> /**
>  * This is a class.
>  */
> public class A {}
> ```
> 
> or
> 
> ```java
> /**
>  * This is a class.
>  */
> 
> public class A {}
> ```
> 
> Which is the most common? Which is preferred?

We do not have an overall style guide.   The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067156407

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <plSw9jOH-0xxK5ZFqpYVa_RdLe0jGTIrrmOije3GV2c=.8c3f6569-fdfb-4fe8-b501-78f5da7fdf74@github.com>

On Fri, 19 Apr 2024 10:49:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>>   
>>   Fix grammatical typo
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * Open an file input stream given a URL.
> 
> Suggestion:
> 
>  * Open a file input stream given a URL.

OK, I'll accept this as a minor typo mixup, that does not in itself need a CSR. But generally, it is not a goal to fix issues in the content of doc comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572821973

From rmahajan at openjdk.org  Fri Apr 19 19:22:58 2024
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Fri, 19 Apr 2024 19:22:58 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <_22Iauno9nyi6hpduwdIZ9i2LjjqK9VtiCQbzY8GCNU=.1eeff288-1725-419e-9abd-584511f38ff9@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

Changes requested by rmahajan (Author).

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 120:

> 118:     // this should be called only with writeLock held
> 119:     private static Long getThemeImpl(String widget, int dpi) {
> 120:         if (openThemeImpl(widget, dpi) == null || openThemeImpl(widget, dpi) == 0) {

I think it would be cleaner and better if this is handled in `openThemeImpl()` itself. We can put a check for NULL `theme `being returned and return the one based on `defaultDPI`, if that is the case.

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

PR Review: https://git.openjdk.org/jdk/pull/18706#pullrequestreview-2012203269
PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1572824439

From honkar at openjdk.org  Fri Apr 19 19:27:57 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 19 Apr 2024 19:27:57 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <zE0Uj8fxxfhO95uifOTtqVGMBIXvdh_RFSc5HunX8tQ=.89be1852-57cd-4f8d-a940-d6442ea10fa1@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <d4SOTSersooNxNNC3Dd0QJBKyrBKdw9xh0I4ICKqpOw=.f93efbb1-dd97-4c32-b8d9-2c88ea02dacd@github.com>
 <zE0Uj8fxxfhO95uifOTtqVGMBIXvdh_RFSc5HunX8tQ=.89be1852-57cd-4f8d-a940-d6442ea10fa1@github.com>
Message-ID: <6yIaWRTHvaztI8KqtOJ0pdMyyDk-4d9QQaewQ20ClnU=.d7c9f6ac-7552-47b9-ba1b-1e426126f500@github.com>

On Fri, 19 Apr 2024 05:07:19 GMT, Tejesh R <tr at openjdk.org> wrote:

> > @TejeshR13 Based on the PR description the source code fix looks correct. I was unable to test it on my local Win machine due to printer issues. The Print to PDF option isn't working too. But this is something to do with my system config and not related to the fix. Since I wasn't able to test it completely, would like another reviewer to go through it.
> 
> In that case I guess you can test print to pdf using "print to file" checkbox which shows in print dialog, don't have to change the printer name in combobox (I do this in linux).

Same issue with "print to file" and "print to PDF" options.

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2067164842

From jjg at openjdk.org  Fri Apr 19 19:27:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:27:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
Message-ID: <-fG_aheP9IBZLBq6GVU_1peVxqhpa7cQB0cpYK7cdDY=.b81305e0-56d5-4df2-9ac2-ca73e6433177@github.com>

On Fri, 19 Apr 2024 11:32:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:
> 
> ```
> /**
>  * @test TestSmallHeap
>  * @bug 8067438 8152239
>  * @summary Verify that starting the VM with a small heap works
>  * @library /test/lib
>  * @modules java.base/jdk.internal.misc
>  * @build jdk.test.whitebox.WhiteBox
>  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>  * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
>  */
> ```
> 
> I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

I agree we should not be using `/**` for test description comments.
IntelliJ tells me there are 103+ matches in 97+ files, so this would be a non-trivial cleanup. 
I note there are 22 issues in `test/langtools/jdk` tests (i.e. javadoc tests), so let's start there ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067164929

From aivanov at openjdk.org  Fri Apr 19 19:32:57 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <Lq-Q7ZUwaTVlfO51UDbEwlePabsWtebfX4r-DIObVwU=.fd2569b7-0595-4661-a841-aa890b9c3daa@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012219677

From aivanov at openjdk.org  Fri Apr 19 19:32:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
Message-ID: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>

On Fri, 19 Apr 2024 19:18:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

That's what I do.

I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067169319

From naoto at openjdk.org  Fri Apr 19 19:51:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 19:51:06 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067190364

From aivanov at openjdk.org  Fri Apr 19 20:10:06 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 20:10:06 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <pb725E6yNGteo1kXIzd1U2haHQ94apMva4QE1tgoC2Y=.594ca785-a24a-4208-a100-beaa35973f0d@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

Changes requested by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18706#pullrequestreview-2012244251

From aivanov at openjdk.org  Fri Apr 19 20:10:33 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 20:10:33 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null
In-Reply-To: <_22Iauno9nyi6hpduwdIZ9i2LjjqK9VtiCQbzY8GCNU=.1eeff288-1725-419e-9abd-584511f38ff9@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <_22Iauno9nyi6hpduwdIZ9i2LjjqK9VtiCQbzY8GCNU=.1eeff288-1725-419e-9abd-584511f38ff9@github.com>
Message-ID: <JKadBrmOfX6wXmzFnMjJzlmKG1tjXG9Hag9YQdJ9G7E=.5af46af7-15d6-4bf6-9674-8876a19e8f6f@github.com>

On Fri, 19 Apr 2024 19:19:26 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

>> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
>> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).
>
> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 120:
> 
>> 118:     // this should be called only with writeLock held
>> 119:     private static Long getThemeImpl(String widget, int dpi) {
>> 120:         if (openThemeImpl(widget, dpi) == null || openThemeImpl(widget, dpi) == 0) {
> 
> I think it would be cleaner and better if this is handled in `openThemeImpl()` itself. We can put a check for NULL `theme `being returned and return the one based on `defaultDPI`, if that is the case.

I agree. The current approach calls `openThemeImpl` three times: once or twice with the passed `dpi` and then once with `defaultDPI` as the fallback. Moreover, it *leaks theme handles* if `openThemeImpl` returns non-zero value and it does so repeatedly even when there's a cached theme handle.

Handling the failure inside `openThemeImpl` seems a better option. Even though it results in a higher memory usage.

I believe `openTheme` returns 0 because the DPI of a printer is higher than that of screens, and Windows doesn't support such DPIs. The problem is likely reproducible when you print other components such as buttons.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1572847417

From liach at openjdk.org  Fri Apr 19 20:27:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 19 Apr 2024 20:27:29 GMT
Subject: RFR: 8323965: modify fix for 8317771 to remove reflection
 instantiation of the inner class
In-Reply-To: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
References: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
Message-ID: <OhejtXNIUu2_wIKiNHKhhPZ_8Uf1Xwn1WqoTtDNOJ5A=.7d018be5-c2d0-4be6-a17f-236fa1966031@github.com>

On Fri, 19 Apr 2024 15:16:41 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> I replaced reflection with using an accessor
> @azuev-java please review

src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 331:

> 329:         var access = accessibleJTreeNodeCreateAccessor;
> 330:         if (access == null) {
> 331:             ensureClassInitialized(JTree.class);

This probably doesn't work as JTree class initialization does not seem to trigger AccessibleJTree class initialization. The other one for AccessibleJTreeNode is dubious too, maybe it just happens that all accesses are correctly made only after the related classes are initialized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18867#discussion_r1572913874

From jjg at openjdk.org  Fri Apr 19 20:36:30 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 20:36:30 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
Message-ID: <H9YDeHC1vbzTbg9fB2HdGaLMDU1BuKqekRT-kLMyGKU=.2d7b6fc4-b059-4944-89b3-67004dac6ea0@github.com>

On Fri, 19 Apr 2024 19:47:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

@naotoj Given the policy and strong desire to compile `java.base` with all lint warnings enabled and `-Werror`, all of the proposed changes in this PR will each individually break the build if/when the warning is added to `javac` and we continue to compile `java.base` with the current build settings.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067246948

From naoto at openjdk.org  Fri Apr 19 20:40:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 20:40:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

OK, fair enough. Approving for the `icu` part

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012372872

From jjg at openjdk.org  Fri Apr 19 21:07:02 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 21:07:02 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
Message-ID: <7LlnKXolx2fp1kJEq5_UYjcC-q0Y8AF2hidczf7kPl8=.bcfb39c9-9992-44ee-9cec-8bfcda42dd9b@github.com>

On Fri, 19 Apr 2024 20:38:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> OK, fair enough. Approving for the `icu` part

Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067280359

From tr at openjdk.org  Mon Apr 22 07:08:00 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 22 Apr 2024 07:08:00 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

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

  Moved failure handling inside openThemeImpl method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18706/files
  - new: https://git.openjdk.org/jdk/pull/18706/files/63ef9f50..6f5a5c90

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

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

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

From tr at openjdk.org  Mon Apr 22 07:08:00 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 22 Apr 2024 07:08:00 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <JKadBrmOfX6wXmzFnMjJzlmKG1tjXG9Hag9YQdJ9G7E=.5af46af7-15d6-4bf6-9674-8876a19e8f6f@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <_22Iauno9nyi6hpduwdIZ9i2LjjqK9VtiCQbzY8GCNU=.1eeff288-1725-419e-9abd-584511f38ff9@github.com>
 <JKadBrmOfX6wXmzFnMjJzlmKG1tjXG9Hag9YQdJ9G7E=.5af46af7-15d6-4bf6-9674-8876a19e8f6f@github.com>
Message-ID: <ejBBqmCOhosuRvuRaJTi4juKe6Rt8Xw2LWF_Vnc85ho=.9f33a623-40ac-4502-a15b-d29303fe733f@github.com>

On Fri, 19 Apr 2024 19:46:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 120:
>> 
>>> 118:     // this should be called only with writeLock held
>>> 119:     private static Long getThemeImpl(String widget, int dpi) {
>>> 120:         if (openThemeImpl(widget, dpi) == null || openThemeImpl(widget, dpi) == 0) {
>> 
>> I think it would be cleaner and better if this is handled in `openThemeImpl()` itself. We can put a check for NULL `theme `being returned and return the one based on `defaultDPI`, if that is the case.
>
> I agree. The current approach calls `openThemeImpl` three times: once or twice with the passed `dpi` and then once with `defaultDPI` as the fallback. Moreover, it *leaks theme handles* if `openThemeImpl` returns non-zero value and it does so repeatedly even when there's a cached theme handle.
> 
> Handling the failure inside `openThemeImpl` seems a better option. Even though it results in a higher memory usage.
> 
> I believe `openTheme` returns 0 because the DPI of a printer is higher than that of screens, and Windows doesn't support such DPIs. The problem is likely reproducible when you print other components such as buttons.

Yes, `openTheme()` actually returns 0. Hence I used `null` && `0` checker.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1574224390

From tr at openjdk.org  Mon Apr 22 07:08:00 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 22 Apr 2024 07:08:00 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <ejBBqmCOhosuRvuRaJTi4juKe6Rt8Xw2LWF_Vnc85ho=.9f33a623-40ac-4502-a15b-d29303fe733f@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <_22Iauno9nyi6hpduwdIZ9i2LjjqK9VtiCQbzY8GCNU=.1eeff288-1725-419e-9abd-584511f38ff9@github.com>
 <JKadBrmOfX6wXmzFnMjJzlmKG1tjXG9Hag9YQdJ9G7E=.5af46af7-15d6-4bf6-9674-8876a19e8f6f@github.com>
 <ejBBqmCOhosuRvuRaJTi4juKe6Rt8Xw2LWF_Vnc85ho=.9f33a623-40ac-4502-a15b-d29303fe733f@github.com>
Message-ID: <SEBMVB1FKLg18QEBR7BrLFpWFP2G_b6l6tIPhda2-Os=.d76dd5c9-d230-4415-8b64-19e0a243b4cc@github.com>

On Mon, 22 Apr 2024 07:00:52 GMT, Tejesh R <tr at openjdk.org> wrote:

>> I agree. The current approach calls `openThemeImpl` three times: once or twice with the passed `dpi` and then once with `defaultDPI` as the fallback. Moreover, it *leaks theme handles* if `openThemeImpl` returns non-zero value and it does so repeatedly even when there's a cached theme handle.
>> 
>> Handling the failure inside `openThemeImpl` seems a better option. Even though it results in a higher memory usage.
>> 
>> I believe `openTheme` returns 0 because the DPI of a printer is higher than that of screens, and Windows doesn't support such DPIs. The problem is likely reproducible when you print other components such as buttons.
>
> Yes, `openTheme()` actually returns 0. Hence I used `null` && `0` checker.

Moved the failure handling to `openThemeImpl()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1574227636

From tr at openjdk.org  Mon Apr 22 07:21:29 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 22 Apr 2024 07:21:29 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
Message-ID: <Wz3PdTw8z-YsZMNlD2qKVNUCy7PRDKAMNcmP7MTyZ-k=.245b88e1-33a2-42f2-9f53-39abafab58d7@github.com>

On Fri, 19 Apr 2024 14:53:09 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearranged if based on suggesion

src/java.desktop/share/classes/javax/swing/JEditorPane.java line 483:

> 481:             // The same page with different reference
> 482:             if (reference != null) {
> 483:                 scrollToReference(reference);

Do we need to move ` scrollToReference(reference);` to swingUtil ? If not any reason for invoking it in swingUtil at line 547 and not here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1574244776

From tr at openjdk.org  Mon Apr 22 08:43:33 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 22 Apr 2024 08:43:33 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <Wz3PdTw8z-YsZMNlD2qKVNUCy7PRDKAMNcmP7MTyZ-k=.245b88e1-33a2-42f2-9f53-39abafab58d7@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
 <Wz3PdTw8z-YsZMNlD2qKVNUCy7PRDKAMNcmP7MTyZ-k=.245b88e1-33a2-42f2-9f53-39abafab58d7@github.com>
Message-ID: <Ivy0qSVwoBtqEMPf0KBjEv8QAHM52tfFgZevyBzxM1s=.58908454-3a6b-4772-82f0-8596af0d30f8@github.com>

On Mon, 22 Apr 2024 07:19:04 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rearranged if based on suggesion
>
> src/java.desktop/share/classes/javax/swing/JEditorPane.java line 483:
> 
>> 481:             // The same page with different reference
>> 482:             if (reference != null) {
>> 483:                 scrollToReference(reference);
> 
> Do we need to move ` scrollToReference(reference);` to swingUtil ? If not any reason for invoking it in swingUtil at line 547 and not here?

Is it because of same page which is already loaded and no reloading is required?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1574365849

From pminborg at openjdk.org  Mon Apr 22 08:46:53 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 Apr 2024 08:46:53 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v7]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

 - Simplify tests
 - Add a test for null arg
 - Add a test for findOrThrow()
 - Merge branch 'master' into symbol-lookup-findorthrow
 - Change exception type
 - Update src/java.base/share/classes/java/lang/foreign/package-info.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - Fix typo
 - Update after PR comments
 - ... and 2 more: https://git.openjdk.org/jdk/compare/76cd531f...0e06e0d6

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/e2f6c4c9..0e06e0d6

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

  Stats: 91042 lines in 1455 files changed: 42444 ins; 38886 del; 9712 mod
  Patch: https://git.openjdk.org/jdk/pull/18474.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18474/head:pull/18474

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

From asemenov at openjdk.org  Mon Apr 22 10:00:29 2024
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 22 Apr 2024 10:00:29 GMT
Subject: RFR: 8323965: modify fix for 8317771 to remove reflection
 instantiation of the inner class
In-Reply-To: <OhejtXNIUu2_wIKiNHKhhPZ_8Uf1Xwn1WqoTtDNOJ5A=.7d018be5-c2d0-4be6-a17f-236fa1966031@github.com>
References: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
 <OhejtXNIUu2_wIKiNHKhhPZ_8Uf1Xwn1WqoTtDNOJ5A=.7d018be5-c2d0-4be6-a17f-236fa1966031@github.com>
Message-ID: <cQeNjNWBM9RnHh0mD8ZPfulXaZ1c257OJNVVOwrY5TM=.75fbed09-6bcc-467a-a30e-e036f503a5ad@github.com>

On Fri, 19 Apr 2024 20:24:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I replaced reflection with using an accessor
>> @azuev-java please review
>
> src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 331:
> 
>> 329:         var access = accessibleJTreeNodeCreateAccessor;
>> 330:         if (access == null) {
>> 331:             ensureClassInitialized(JTree.class);
> 
> This probably doesn't work as JTree class initialization does not seem to trigger AccessibleJTree class initialization. The other one for AccessibleJTreeNode is dubious too, maybe it just happens that all accesses are correctly made only after the related classes are initialized.

This line calls the ```ensureClassInitialized()``` method, which performs a full initialization of the class... It calls: ```MethodHandles.lookup().ensureInitialized()```, which, as stated in the documentation , performs a full initialization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18867#discussion_r1574478565

From liach at openjdk.org  Mon Apr 22 11:52:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Apr 2024 11:52:28 GMT
Subject: RFR: 8323965: modify fix for 8317771 to remove reflection
 instantiation of the inner class
In-Reply-To: <cQeNjNWBM9RnHh0mD8ZPfulXaZ1c257OJNVVOwrY5TM=.75fbed09-6bcc-467a-a30e-e036f503a5ad@github.com>
References: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
 <OhejtXNIUu2_wIKiNHKhhPZ_8Uf1Xwn1WqoTtDNOJ5A=.7d018be5-c2d0-4be6-a17f-236fa1966031@github.com>
 <cQeNjNWBM9RnHh0mD8ZPfulXaZ1c257OJNVVOwrY5TM=.75fbed09-6bcc-467a-a30e-e036f503a5ad@github.com>
Message-ID: <XRrzAk2qzL4XdzefqaufYEPYBRy4J4MPzN8aNhAQwmE=.c08c5673-8484-479a-8c82-349f0a067b05@github.com>

On Mon, 22 Apr 2024 09:57:28 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> src/java.desktop/share/classes/sun/swing/SwingAccessor.java line 331:
>> 
>>> 329:         var access = accessibleJTreeNodeCreateAccessor;
>>> 330:         if (access == null) {
>>> 331:             ensureClassInitialized(JTree.class);
>> 
>> This probably doesn't work as JTree class initialization does not seem to trigger AccessibleJTree class initialization. The other one for AccessibleJTreeNode is dubious too, maybe it just happens that all accesses are correctly made only after the related classes are initialized.
>
> This line calls the ```ensureClassInitialized()``` method, which performs a full initialization of the class... It calls: ```MethodHandles.lookup().ensureInitialized()```, which, as stated in the documentation , performs a full initialization.

I know, but initializing a class does not necessarily initialize its nested/inner classes

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18867#discussion_r1574623725

From mcimadamore at openjdk.org  Mon Apr 22 13:49:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 Apr 2024 13:49:37 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v7]
In-Reply-To: <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>
Message-ID: <YqMHwwkz2Lezr2Mvaav4QLyOAaO1OrjMCq8R3nhBpdA=.6ad77975-989f-42eb-9644-f3b576b68f00@github.com>

On Mon, 22 Apr 2024 08:46:53 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
>> 
>> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Simplify tests
>  - Add a test for null arg
>  - Add a test for findOrThrow()
>  - Merge branch 'master' into symbol-lookup-findorthrow
>  - Change exception type
>  - Update src/java.base/share/classes/java/lang/foreign/package-info.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>    
>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>  - Fix typo
>  - Update after PR comments
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/9a68d47d...0e06e0d6

test/jdk/java/foreign/loaderLookup/TestSymbolLookupFindOrThrow.java line 41:

> 39: 
> 40:     static {
> 41:         System.loadLibrary("Foo");

Where is this lib defined?

test/jdk/java/foreign/loaderLookup/TestSymbolLookupFindOrThrow.java line 58:

> 56:     @Test
> 57:     void findOrThrowNullArg() {
> 58:         assertThrows(NullPointerException.class, () ->

I believe this should already be checked by the TestNulls test - which is a test that automatically checks that _all_ API methods handle nulls accordingly. Please check that, and maybe remove this?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1574788219
PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1574786946

From aivanov at openjdk.org  Mon Apr 22 15:06:30 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 15:06:30 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <Ivy0qSVwoBtqEMPf0KBjEv8QAHM52tfFgZevyBzxM1s=.58908454-3a6b-4772-82f0-8596af0d30f8@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
 <Wz3PdTw8z-YsZMNlD2qKVNUCy7PRDKAMNcmP7MTyZ-k=.245b88e1-33a2-42f2-9f53-39abafab58d7@github.com>
 <Ivy0qSVwoBtqEMPf0KBjEv8QAHM52tfFgZevyBzxM1s=.58908454-3a6b-4772-82f0-8596af0d30f8@github.com>
Message-ID: <TUEaLOJNzCAmzAF4CBprOk08_tIb8fKXJboRoiOXDI4=.2161b2c3-7b55-4ee8-969f-10a94e377f65@github.com>

On Mon, 22 Apr 2024 08:41:13 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/share/classes/javax/swing/JEditorPane.java line 483:
>> 
>>> 481:             // The same page with different reference
>>> 482:             if (reference != null) {
>>> 483:                 scrollToReference(reference);
>> 
>> Do we need to move ` scrollToReference(reference);` to swingUtil ? If not any reason for invoking it in swingUtil at line 547 and not here?
>
> Is it because of same page which is already loaded and no reloading is required?

Yes, the page is already loaded, it's rendered, so the location to scroll to can be calculated right away.

Below, there's a comment:
https://github.com/openjdk/jdk/blob/be168e9d331ead58503ac3a01dae0bd98ae42d5e/src/java.desktop/share/classes/javax/swing/JEditorPane.java#L544-L549

This piece of code is unchanged. The new document is just loaded. To calculate the location to scroll to, the view hierarchy needs to be created and laid out; this is why `invokeLater` is used ? to delay calculating the position.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18670#discussion_r1574917367

From aivanov at openjdk.org  Mon Apr 22 15:12:30 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 15:12:30 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
Message-ID: <Tp39ngbiUIS96X6n5KWeoLY2M96tAwDHp8X9bovADJQ=.af89e257-4fe7-49f9-b006-070495406d10@github.com>

On Mon, 22 Apr 2024 07:08:00 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
>> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved failure handling inside openThemeImpl method

Changes requested by aivanov (Reviewer).

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 117:

> 115:        if (theme == null || theme == 0) {
> 116:            theme = openTheme(widget, defaultDPI);
> 117:        }

`theme` can't be `null` because `openTheme` returns `long`. Perhaps, the declaration should be changed to

long theme;


This is still incorrect. If `i > 0`, there's a prerequisite to calling `openTheme`. Likely, you need another helper method.

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

PR Review: https://git.openjdk.org/jdk/pull/18706#pullrequestreview-2015052771
PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1574925429

From aivanov at openjdk.org  Mon Apr 22 15:17:29 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 15:17:29 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
Message-ID: <NlbDjSlt-lpbkwrBxfn24PhbhDNRH3dgelUKQwq2d80=.0da4ff2e-b1ef-4dd8-9e0d-bcfa032a0de9@github.com>

On Mon, 22 Apr 2024 07:08:00 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
>> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Moved failure handling inside openThemeImpl method

Do you mind if I shorten the subject of the bug? _Printing JTable throws InternalError: HTHEME is null_?

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2069838938

From aivanov at openjdk.org  Mon Apr 22 15:17:30 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 15:17:30 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <SEBMVB1FKLg18QEBR7BrLFpWFP2G_b6l6tIPhda2-Os=.d76dd5c9-d230-4415-8b64-19e0a243b4cc@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <_22Iauno9nyi6hpduwdIZ9i2LjjqK9VtiCQbzY8GCNU=.1eeff288-1725-419e-9abd-584511f38ff9@github.com>
 <JKadBrmOfX6wXmzFnMjJzlmKG1tjXG9Hag9YQdJ9G7E=.5af46af7-15d6-4bf6-9674-8876a19e8f6f@github.com>
 <ejBBqmCOhosuRvuRaJTi4juKe6Rt8Xw2LWF_Vnc85ho=.9f33a623-40ac-4502-a15b-d29303fe733f@github.com>
 <SEBMVB1FKLg18QEBR7BrLFpWFP2G_b6l6tIPhda2-Os=.d76dd5c9-d230-4415-8b64-19e0a243b4cc@github.com>
Message-ID: <lWgcCWDzOnJKwvpmM9L_Mcu6KZJ2zB4vDe9y7dosxpc=.f24eae72-8b47-412b-852b-149cdea5b887@github.com>

On Mon, 22 Apr 2024 07:03:54 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Yes, `openTheme()` actually returns 0. Hence I used `null` && `0` checker.
>
> Moved the failure handling to `openThemeImpl()`.

> Yes, `openTheme()` actually returns 0. ?

This is why it can't be `null`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1574932209

From achung at openjdk.org  Mon Apr 22 16:08:28 2024
From: achung at openjdk.org (Alisen Chung)
Date: Mon, 22 Apr 2024 16:08:28 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
Message-ID: <P6AD2y50iYCcyd8HJJJdIbsCEMyjL0xG8GeUxEKlUxw=.494ed4d5-026f-4822-8009-9f0741979c84@github.com>

On Fri, 19 Apr 2024 07:12:36 GMT, Tejesh R <tr at openjdk.org> wrote:

> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
> PassFailJFrame.builder is used.

Changes requested by achung (Committer).

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 102:

> 100:         colorColumn.setCellRenderer(colorColumnRenderer);
> 101: 
> 102:         // Set a tooltip for the header of the color's column.

I think `Set a tooltip for the header of the color column` would be technically correct?

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 130:

> 128:         frame.add(scrollPane);
> 129:         frame.pack();
> 130:         frame.setVisible(true);

no need for frame.setVisible since PassFailJFrame will do that

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

PR Review: https://git.openjdk.org/jdk/pull/18855#pullrequestreview-2015214194
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575014694
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575012265

From jjg at openjdk.org  Mon Apr 22 17:41:28 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 22 Apr 2024 17:41:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
Message-ID: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>

On Fri, 19 Apr 2024 19:29:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.
> 
> That's what I do.
> 
> I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

>Footnotes
>
> [1] At Java Software, we use @version for the SCCS version. See "man sccs-get" for details. The consensus seems to be the following:

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070379608

From aivanov at openjdk.org  Mon Apr 22 17:56:28 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 17:56:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
 <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
Message-ID: <00Gbr5mrPAEDVFsF8tkDSasn1qIk1OftDX9nvExC9mg=.c3313acd-0939-4af8-9c36-e9c8b7e6e518@github.com>

On Mon, 22 Apr 2024 17:38:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

I know. Yet there's nothing newer, is there?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070433346

From dnguyen at openjdk.org  Mon Apr 22 21:37:29 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Apr 2024 21:37:29 GMT
Subject: RFR: 8329559: Test javax/swing/JFrame/bug4419914.java failed
 because The End and Start buttons are not placed correctly and Tab focus does
 not move as expected [v2]
In-Reply-To: <D1KA3JdD9qQ4HW5IOrXIpw_B22yxJGegx55Nj4tZsJ0=.2e4709c4-8b18-412f-82be-a2cf92df188e@github.com>
References: <Rf-lMOQUO3KFfWj0L2QJtk1ttfLhV15txVicyGpy6mY=.3c78b630-0757-4302-80c0-00cab7b296a0@github.com>
 <D1KA3JdD9qQ4HW5IOrXIpw_B22yxJGegx55Nj4tZsJ0=.2e4709c4-8b18-412f-82be-a2cf92df188e@github.com>
Message-ID: <RkgH2ZqiGPLxHUR7Ad1uUVp5T4H8v2ryKzLUeONRQrk=.0ac90b74-a4dc-4f7f-8101-405939c0221a@github.com>

On Thu, 4 Apr 2024 09:38:20 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Test issue shows the End and Start buttons are not placed as per instructions due to ComponentOrientation RTL was not honoured, as with `getContentPane()` being removed from `add` call of JFrame, it was also additionally removed from other JFrame calls which resulted in the RTL not being propagated to its child. Fix is to add `getContentPane()` to the non-add methods of JFrame as was done in the applet version of the test..
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   instruction formatting

Changes LGTM. Behaving as expected.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18612#pullrequestreview-2015842312

From dnguyen at openjdk.org  Mon Apr 22 21:43:28 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Apr 2024 21:43:28 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
Message-ID: <NPTdHJ3NF8m6v4emHTZVZPWJLWSuhJD3bNZohu9DUoo=.6ba73b57-c96a-47d7-80bd-9a8d98fd025a@github.com>

On Fri, 19 Apr 2024 07:12:36 GMT, Tejesh R <tr at openjdk.org> wrote:

> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
> PassFailJFrame.builder is used.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 190:

> 188:         PassFailJFrame.builder()
> 189:                 .instructions(INSTRUCTIONS)
> 190:                 .rows(11)

Suggestion:

                .rows((int) INSTRUCTIONS.lines().count() + 2)


This is what we used for our tests. I default to using this now myself.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575387607

From dnguyen at openjdk.org  Mon Apr 22 21:52:29 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Mon, 22 Apr 2024 21:52:29 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
Message-ID: <ekWpMfgbu8iBxX3k6OtekAFfgQjKu-1vnVsUEDpTmpw=.fdb551b0-ecea-483d-8e8c-0443faab4b69@github.com>

On Fri, 19 Apr 2024 07:12:36 GMT, Tejesh R <tr at openjdk.org> wrote:

> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
> PassFailJFrame.builder is used.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 235:

> 233:                 Control-shift-PageUp/PageDown - extend selection left/right
> 234:                                                 end of row
> 235:                 """;

I see that for "Navigate In", you mix capitalization for `Tab` and `shift-tab`. Looks a bit off. Maybe better to standardize capitalization for keys. Maybe title-case or all-caps the key names.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575393833

From kizune at openjdk.org  Tue Apr 23 02:28:28 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Tue, 23 Apr 2024 02:28:28 GMT
Subject: RFR: 8323965: modify fix for 8317771 to remove reflection
 instantiation of the inner class
In-Reply-To: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
References: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
Message-ID: <8UUGuCSVNJc9qzgMr7dMD8Vjgk0QqtYL2NDPgwHZYUE=.3211e063-6266-44bf-9b1f-84bdffc6d3a0@github.com>

On Fri, 19 Apr 2024 15:16:41 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> I replaced reflection with using an accessor
> @azuev-java please review

The problem with this fix is that on the test example attached to the bug any attempt of navigation trough the items of JTree whole voice over is enabled causes java to stop responding. I see in the logs that it does call this exact place thousands of time constantly. So it seems like it makes the problem with java stalling on large size trees to re-appear.

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

PR Comment: https://git.openjdk.org/jdk/pull/18867#issuecomment-2071292444

From darcy at openjdk.org  Tue Apr 23 02:29:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 Apr 2024 02:29:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <S6J882dLjdmFPXHVRQm77lTy73k9FIGC_-kDiBLael4=.0191a2c7-4f55-41b8-a389-e238c8b63f84@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016121831

From iris at openjdk.org  Tue Apr 23 02:35:31 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 Apr 2024 02:35:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <QuHZeejL48phB87kuWRWzlunHQ6KGRSVvyNNCVjTFzk=.1edeb3eb-3cd6-4ed3-a0b5-1a39937dd7e3@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016126206

From serb at openjdk.org  Tue Apr 23 03:39:26 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 23 Apr 2024 03:39:26 GMT
Subject: RFR: 8328896: Fontmetrics for large Fonts has zero width
In-Reply-To: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
References: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
Message-ID: <3mHd742WWTRQoz41i8ibJ7jvlsz3NMfwpsunUlOH5VU=.f3b9b45a-e4fc-4a0b-862d-bf487fc39ff8@github.com>

On Tue, 9 Apr 2024 18:50:17 GMT, Phil Race <prr at openjdk.org> wrote:

> The main problem here is that we do not curate what font point size we passed to freetype,
> and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
> This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
> But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
> values, so 32767 is really the max.
> But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
> And we can request bigger sizes than that by making use of the transform.
> At normal size ranges we use that just to account for rotation and decompose the glyph transform
> into point size and that rotation.
> 
> But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
> from not specifying the target point size. So we can extend the range of sizes we allow.
> 
> If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
> a for a NaN transform.
> 
> These extreme values aren't useful.
> 
> In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
> for rendering. Which is not useful and could lead to inconsistent results. I fixed that.
> 
> Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.
> 
> The test is mainly around making sure that "sensible" things are returned for not sensible input.
> There's no 100% right answer to these extreme unrenderable sizes.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18703#pullrequestreview-2016175337

From tr at openjdk.org  Tue Apr 23 04:39:27 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 04:39:27 GMT
Subject: RFR: 8328896: Fontmetrics for large Fonts has zero width
In-Reply-To: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
References: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
Message-ID: <PSIy1XpBXxgoh64ZdQbNXz0T4fqr2MIToPXLFfy2IhA=.bec33e19-76b7-463b-974a-bedef423e24c@github.com>

On Tue, 9 Apr 2024 18:50:17 GMT, Phil Race <prr at openjdk.org> wrote:

> The main problem here is that we do not curate what font point size we passed to freetype,
> and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
> This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
> But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
> values, so 32767 is really the max.
> But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
> And we can request bigger sizes than that by making use of the transform.
> At normal size ranges we use that just to account for rotation and decompose the glyph transform
> into point size and that rotation.
> 
> But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
> from not specifying the target point size. So we can extend the range of sizes we allow.
> 
> If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
> a for a NaN transform.
> 
> These extreme values aren't useful.
> 
> In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
> for rendering. Which is not useful and could lead to inconsistent results. I fixed that.
> 
> Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.
> 
> The test is mainly around making sure that "sensible" things are returned for not sensible input.
> There's no 100% right answer to these extreme unrenderable sizes.

LGTM.

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18703#pullrequestreview-2016218880

From tr at openjdk.org  Tue Apr 23 05:05:28 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 05:05:28 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <NlbDjSlt-lpbkwrBxfn24PhbhDNRH3dgelUKQwq2d80=.0da4ff2e-b1ef-4dd8-9e0d-bcfa032a0de9@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
 <NlbDjSlt-lpbkwrBxfn24PhbhDNRH3dgelUKQwq2d80=.0da4ff2e-b1ef-4dd8-9e0d-bcfa032a0de9@github.com>
Message-ID: <TTN-J7bXdWpjHVtQeGrj7-E6g0BnsyIGYYZREsJDd00=.ecd61cf3-c728-42e7-8c7c-c68a48fd2095@github.com>

On Mon, 22 Apr 2024 15:14:41 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Do you mind if I shorten the subject of the bug? _Printing JTable throws InternalError: HTHEME is null_?

Sure, it's better to shorten it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2071413388

From tr at openjdk.org  Tue Apr 23 06:15:29 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 06:15:29 GMT
Subject: RFR: 8328977 : JEditorPane.setPage not thread-safe,
 pageLoader not cancelled [v3]
In-Reply-To: <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
References: <hn5geQRIWj7OwCFOao-TT9ZxiZRr-k--WMsBrddOwzo=.d8a49243-863f-4820-a338-363426a361d8@github.com>
 <mDuu2F6u15QwZmsLmEpy1MCBrthKL6Ysnc_ZiCnvcn8=.deb32b9c-3099-441e-a08a-8ca7158e7b9c@github.com>
Message-ID: <Ps4uriCyLspGqHwhsQwlOJLGHLLpYHiO66oG24Xrco0=.71777fcd-2a98-448c-8fe0-8285a22e52c0@github.com>

On Fri, 19 Apr 2024 14:53:09 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Added pageloader cancel before new page creation along with code restructuring. Moved all page loading calls inside synchronize to make it thread safe.
>> 
>> Regards,
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rearranged if based on suggesion

LGTM

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

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18670#pullrequestreview-2016320923

From tr at openjdk.org  Tue Apr 23 06:33:56 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 06:33:56 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v3]
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <HvkK0C39NZNxvSwPF4RH8_TbxBSMj7KLKRKZPlKg-lQ=.bf445f5b-de40-457a-82e2-cd61a3a8b7d1@github.com>

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

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

  Review updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18706/files
  - new: https://git.openjdk.org/jdk/pull/18706/files/6f5a5c90..f78ed3e0

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

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

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

From abhiscxk at openjdk.org  Tue Apr 23 06:50:28 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 23 Apr 2024 06:50:28 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
Message-ID: <2RvjW-UfxCQmGzra3zzt9l643x1Z2lPreUqNHrGGxdU=.54c5e639-a4c8-455f-93a8-de0d6f7ea923@github.com>

On Fri, 19 Apr 2024 07:12:36 GMT, Tejesh R <tr at openjdk.org> wrote:

> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
> PassFailJFrame.builder is used.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 105:

> 103:         TableCellRenderer headerRenderer = colorColumn.getHeaderRenderer();
> 104:         if (headerRenderer instanceof DefaultTableCellRenderer)
> 105:             ((DefaultTableCellRenderer) headerRenderer).setToolTipText("Hi Mom!");

Suggestion:
Usage of enhanced `instanceOf` avoids the casting to `DefaultTableCellRenderer` below. Use `{ }` for single if statement too.

Suggestion:

        if (colorColumn.getHeaderRenderer() instanceof DefaultTableCellRenderer headerRenderer ) {
           headerRenderer.setToolTipText("Hi Mom!");
       }


Same can be used at L115 as well.
`int cellValue = (value instanceof Number number) ? number.intValue() : 0;`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575722342

From asemenov at openjdk.org  Tue Apr 23 07:13:36 2024
From: asemenov at openjdk.org (Artem Semenov)
Date: Tue, 23 Apr 2024 07:13:36 GMT
Subject: RFR: 8323965: modify fix for 8317771 to remove reflection
 instantiation of the inner class
In-Reply-To: <8UUGuCSVNJc9qzgMr7dMD8Vjgk0QqtYL2NDPgwHZYUE=.3211e063-6266-44bf-9b1f-84bdffc6d3a0@github.com>
References: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
 <8UUGuCSVNJc9qzgMr7dMD8Vjgk0QqtYL2NDPgwHZYUE=.3211e063-6266-44bf-9b1f-84bdffc6d3a0@github.com>
Message-ID: <nF6LDWBq55pDoDvlU6wRDL9vQYSIPnmcqAWdrcH8Z-U=.47f0b945-a9f3-40c9-9d79-427b1f60c45b@github.com>

On Tue, 23 Apr 2024 02:25:57 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> I replaced reflection with using an accessor
>> @azuev-java please review
>
> The problem with this fix is that on the test example attached to the bug any attempt of navigation trough the items of JTree whole voice over is enabled causes java to stop responding. I see in the logs that it does call this exact place thousands of time constantly. So it seems like it makes the problem with java stalling on large size trees to re-appear.

@azuev-java 
I'm restoring the context: There was a cycle that recursively collected children, and on new MacOS it worked for a very long time.. JDK-8317771 .
I added a solution for JTree, which works much faster, but there was a reflection, you asked to remove it. Unlike the old algorithm, it now works in seconds, not minutes...
The essence of JDK-8329667 is that the custom tree did not work due to reflection.
I removed the reflection, I did not add any additional acceleration.
As for speeding up the tree, I suggest adding caching, similar to how it is implemented in tables.

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

PR Comment: https://git.openjdk.org/jdk/pull/18867#issuecomment-2071587990

From tr at openjdk.org  Tue Apr 23 07:14:41 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 07:14:41 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <Tp39ngbiUIS96X6n5KWeoLY2M96tAwDHp8X9bovADJQ=.af89e257-4fe7-49f9-b006-070495406d10@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
 <Tp39ngbiUIS96X6n5KWeoLY2M96tAwDHp8X9bovADJQ=.af89e257-4fe7-49f9-b006-070495406d10@github.com>
Message-ID: <x_m7EhGlHtNjZN1-xoDTkIQY5BSOf278otXsI0A4OzI=.6024316c-a22e-415b-b45d-24c769574cea@github.com>

On Mon, 22 Apr 2024 15:09: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:
>> 
>>   Moved failure handling inside openThemeImpl method
>
> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 117:
> 
>> 115:        if (theme == null || theme == 0) {
>> 116:            theme = openTheme(widget, defaultDPI);
>> 117:        }
> 
> `theme` can't be `null` because `openTheme` returns `long`. Perhaps, the declaration should be changed to
> 
> long theme;
> 
> 
> This is still incorrect. If `i > 0`, there's a prerequisite to calling `openTheme`. Likely, you need another helper method.

I didn't get the need for helper method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1575758721

From tr at openjdk.org  Tue Apr 23 07:26:33 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 07:26:33 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <P6AD2y50iYCcyd8HJJJdIbsCEMyjL0xG8GeUxEKlUxw=.494ed4d5-026f-4822-8009-9f0741979c84@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
 <P6AD2y50iYCcyd8HJJJdIbsCEMyjL0xG8GeUxEKlUxw=.494ed4d5-026f-4822-8009-9f0741979c84@github.com>
Message-ID: <WzfbZvA5VrUvVuZxXjymMDUKgdx0is78--5qRO0lrCI=.850db88f-4421-4523-82ed-59dda87241e7@github.com>

On Mon, 22 Apr 2024 16:03:12 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
>> PassFailJFrame.builder is used.
>
> test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 130:
> 
>> 128:         frame.add(scrollPane);
>> 129:         frame.pack();
>> 130:         frame.setVisible(true);
> 
> no need for frame.setVisible since PassFailJFrame will do that

Done.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575773246

From tr at openjdk.org  Tue Apr 23 07:29:38 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 07:29:38 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <NPTdHJ3NF8m6v4emHTZVZPWJLWSuhJD3bNZohu9DUoo=.6ba73b57-c96a-47d7-80bd-9a8d98fd025a@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
 <NPTdHJ3NF8m6v4emHTZVZPWJLWSuhJD3bNZohu9DUoo=.6ba73b57-c96a-47d7-80bd-9a8d98fd025a@github.com>
Message-ID: <9AhcFuBYaCp9jPy9ZWZfRSIHm5dOq8mvUwhzq2t_9jk=.e41c2d0b-34e7-4cf6-ba33-2dcd7d58d0cd@github.com>

On Mon, 22 Apr 2024 21:41:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
>> PassFailJFrame.builder is used.
>
> test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 190:
> 
>> 188:         PassFailJFrame.builder()
>> 189:                 .instructions(INSTRUCTIONS)
>> 190:                 .rows(11)
> 
> Suggestion:
> 
>                 .rows((int) INSTRUCTIONS.lines().count() + 2)
> 
> 
> This is what we used for our tests. I default to using this now myself.

This doesn't work here since the Instruction rows are quite more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575777024

From serb at openjdk.org  Tue Apr 23 07:30:32 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 23 Apr 2024 07:30:32 GMT
Subject: RFR: 8319598: SMFParser misinterprets interrupted running status
 [v2]
In-Reply-To: <L83q9-jn2-qpuV2Cto24B80SWaq-qB0lnzSKY_5lUcg=.453ac025-217a-42d1-b0cd-64eb55524cf6@github.com>
References: <zFvFnffplEa7keyW178oiTE4CA9Gdb1eTP_QvditlUU=.7b6b877e-f288-4ae1-8926-777867add334@github.com>
 <L83q9-jn2-qpuV2Cto24B80SWaq-qB0lnzSKY_5lUcg=.453ac025-217a-42d1-b0cd-64eb55524cf6@github.com>
Message-ID: <VAZc-vNxbh8LoRqnM41wnPK-2bTtP1dm5iEpMEmdcd8=.3252e871-2335-4bb9-aae8-0f8324226741@github.com>

On Sat, 11 Nov 2023 12:32:15 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.
>
> Jan Trukenm?ller has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reduced line lengths

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16546#pullrequestreview-2016467422

From tr at openjdk.org  Tue Apr 23 07:37:29 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 07:37:29 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <ekWpMfgbu8iBxX3k6OtekAFfgQjKu-1vnVsUEDpTmpw=.fdb551b0-ecea-483d-8e8c-0443faab4b69@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
 <ekWpMfgbu8iBxX3k6OtekAFfgQjKu-1vnVsUEDpTmpw=.fdb551b0-ecea-483d-8e8c-0443faab4b69@github.com>
Message-ID: <VUVqVr3ExvK3OB4AuGLsTz5gb5jxp6fJ5wMxHNtl2Xg=.e222b5e9-fdd5-40a2-9397-b03b436f4f09@github.com>

On Mon, 22 Apr 2024 21:49:54 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
>> PassFailJFrame.builder is used.
>
> test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 235:
> 
>> 233:                 Control-shift-PageUp/PageDown - extend selection left/right
>> 234:                                                 end of row
>> 235:                 """;
> 
> I see that for "Navigate In", you mix capitalization for `Tab` and `shift-tab`. Looks a bit off. Maybe better to standardize capitalization for keys. Maybe title-case or all-caps the key names.

Sure, I have now Capitalized the Keys.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575786947

From tr at openjdk.org  Tue Apr 23 07:41:32 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 07:41:32 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected
In-Reply-To: <2RvjW-UfxCQmGzra3zzt9l643x1Z2lPreUqNHrGGxdU=.54c5e639-a4c8-455f-93a8-de0d6f7ea923@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
 <2RvjW-UfxCQmGzra3zzt9l643x1Z2lPreUqNHrGGxdU=.54c5e639-a4c8-455f-93a8-de0d6f7ea923@github.com>
Message-ID: <HXqUkViDPpa4hERvUbdLSjGQgYNr9CMm-dP-5SHEjyQ=.cbc8f804-d8c8-45cf-9fca-9dde6aee0093@github.com>

On Tue, 23 Apr 2024 06:44:32 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
>> PassFailJFrame.builder is used.
>
> test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 105:
> 
>> 103:         TableCellRenderer headerRenderer = colorColumn.getHeaderRenderer();
>> 104:         if (headerRenderer instanceof DefaultTableCellRenderer)
>> 105:             ((DefaultTableCellRenderer) headerRenderer).setToolTipText("Hi Mom!");
> 
> Suggestion:
> Usage of enhanced `instanceOf` avoids the casting to `DefaultTableCellRenderer` below. Use `{ }` for single if statement too.
> 
> Suggestion:
> 
>         if (colorColumn.getHeaderRenderer() instanceof DefaultTableCellRenderer headerRenderer ) {
>            headerRenderer.setToolTipText("Hi Mom!");
>        }
> 
> 
> Same can be used at L115 as well.
> `int cellValue = (value instanceof Number number) ? number.intValue() : 0;`

Yeah, updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1575791723

From tr at openjdk.org  Tue Apr 23 07:51:59 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 07:51:59 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected [v2]
In-Reply-To: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
Message-ID: <Kq8Gv5_G7yMscWPJEQ8XQaDyEq5ppUW8RE47c1QNIgE=.0d2fd125-e544-47bf-a4ee-c03a8f0cd5fb@github.com>

> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
> PassFailJFrame.builder is used.

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

  Review updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18855/files
  - new: https://git.openjdk.org/jdk/pull/18855/files/5a999e62..17a87679

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

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

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

From tr at openjdk.org  Tue Apr 23 10:19:40 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 10:19:40 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v4]
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <-j3ayhFDO-jCubw1pJmb624osgh4Pv-V3faVcxgQzTE=.b335c713-8882-4931-806d-cea170c5fe06@github.com>

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

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

  Review updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18706/files
  - new: https://git.openjdk.org/jdk/pull/18706/files/f78ed3e0..9c96cf68

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

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

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

From tr at openjdk.org  Tue Apr 23 10:26:28 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 10:26:28 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <x_m7EhGlHtNjZN1-xoDTkIQY5BSOf278otXsI0A4OzI=.6024316c-a22e-415b-b45d-24c769574cea@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
 <Tp39ngbiUIS96X6n5KWeoLY2M96tAwDHp8X9bovADJQ=.af89e257-4fe7-49f9-b006-070495406d10@github.com>
 <x_m7EhGlHtNjZN1-xoDTkIQY5BSOf278otXsI0A4OzI=.6024316c-a22e-415b-b45d-24c769574cea@github.com>
Message-ID: <X8woKiKhgvZ9k59V50Q3GUUJ39PW8NmSMUDvyWzVvG4=.9e55080e-8ae3-4570-9fbc-fd2031dc7b3b@github.com>

On Tue, 23 Apr 2024 07:11:30 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 117:
>> 
>>> 115:        if (theme == null || theme == 0) {
>>> 116:            theme = openTheme(widget, defaultDPI);
>>> 117:        }
>> 
>> `theme` can't be `null` because `openTheme` returns `long`. Perhaps, the declaration should be changed to
>> 
>> long theme;
>> 
>> 
>> This is still incorrect. If `i > 0`, there's a prerequisite to calling `openTheme`. Likely, you need another helper method.
>
> I didn't get the need for helper method?

Ok, I got it. And I have updated. But if we want to change `theme` to `long`, then I guess we have to do it every calling function I guess. So is it better to leave it as `Long` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576018740

From aivanov at openjdk.org  Tue Apr 23 10:30:30 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Apr 2024 10:30:30 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v4]
In-Reply-To: <-j3ayhFDO-jCubw1pJmb624osgh4Pv-V3faVcxgQzTE=.b335c713-8882-4931-806d-cea170c5fe06@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <-j3ayhFDO-jCubw1pJmb624osgh4Pv-V3faVcxgQzTE=.b335c713-8882-4931-806d-cea170c5fe06@github.com>
Message-ID: <yaCIwCbmtgsAf_T3ba8zxS4DmhKooA4vuRMnpTZGaIo=.24140f72-b763-4b00-9767-6ad0c1047708@github.com>

On Tue, 23 Apr 2024 10:19:40 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
>> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review updates

Looks good to me now.

You should add `8322135` to the list of bugs in the tests which failed because of this bug.

Update the copyright year in modified files.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 110:

> 108:            // See documentation for SetWindowTheme on MSDN.
> 109:            setWindowTheme(widget.substring(0, i));
> 110:            theme = getOpenThemeValue(widget.substring(i + 2), dpi);

I suggest changing the type of `theme` variable from `Long` to `long` as well as the return value of `openThemeImpl`.

src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 125:

> 123:         }
> 124:         return theme;
> 125:     }

Suggestion:

    private static long getOpenThemeValue(String widget, int dpi) {
        long theme = openTheme(widget, dpi);
        if (theme == 0) {
            theme = openTheme(widget, defaultDPI);
        }
        return theme;
    }

Yes, that's what I meant. Let's use the primitive `long`.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18706#pullrequestreview-2016847876
PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576019642
PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576017834

From tr at openjdk.org  Tue Apr 23 10:34:31 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 10:34:31 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v4]
In-Reply-To: <yaCIwCbmtgsAf_T3ba8zxS4DmhKooA4vuRMnpTZGaIo=.24140f72-b763-4b00-9767-6ad0c1047708@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <-j3ayhFDO-jCubw1pJmb624osgh4Pv-V3faVcxgQzTE=.b335c713-8882-4931-806d-cea170c5fe06@github.com>
 <yaCIwCbmtgsAf_T3ba8zxS4DmhKooA4vuRMnpTZGaIo=.24140f72-b763-4b00-9767-6ad0c1047708@github.com>
Message-ID: <8UHAtnWuQ6QiYqkbd_eU-dCG_6wB5mBC7B7JvQH4do4=.95b041d3-190d-4881-b282-931c33809a6e@github.com>

On Tue, 23 Apr 2024 10:24:22 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 updates
>
> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 110:
> 
>> 108:            // See documentation for SetWindowTheme on MSDN.
>> 109:            setWindowTheme(widget.substring(0, i));
>> 110:            theme = getOpenThemeValue(widget.substring(i + 2), dpi);
> 
> I suggest changing the type of `theme` variable from `Long` to `long` as well as the return value of `openThemeImpl`.

Means only till openThemeImpl return value and not further up the hierarchy ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576026977

From aivanov at openjdk.org  Tue Apr 23 10:34:32 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Apr 2024 10:34:32 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <X8woKiKhgvZ9k59V50Q3GUUJ39PW8NmSMUDvyWzVvG4=.9e55080e-8ae3-4570-9fbc-fd2031dc7b3b@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
 <Tp39ngbiUIS96X6n5KWeoLY2M96tAwDHp8X9bovADJQ=.af89e257-4fe7-49f9-b006-070495406d10@github.com>
 <x_m7EhGlHtNjZN1-xoDTkIQY5BSOf278otXsI0A4OzI=.6024316c-a22e-415b-b45d-24c769574cea@github.com>
 <X8woKiKhgvZ9k59V50Q3GUUJ39PW8NmSMUDvyWzVvG4=.9e55080e-8ae3-4570-9fbc-fd2031dc7b3b@github.com>
Message-ID: <T5BwKtl1gXVDjK2drasP83iF-IwmfSvmTuMOtMBo9bY=.ff192fa8-cd21-4849-877d-6827e72dfc59@github.com>

On Tue, 23 Apr 2024 10:23:33 GMT, Tejesh R <tr at openjdk.org> wrote:

>> I didn't get the need for helper method?
>
> Ok, I got it. And I have updated. But if we want to change `theme` to `long`, then I guess we have to do it every calling function I guess. So is it better to leave it as `Long` ?

I still think we should change `Long` to `long`. Yes, you'll need to update it in the two methods. In `getThemeImpl`, it will be boxed into `Long` automatically before being put into the map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576027262

From aivanov at openjdk.org  Tue Apr 23 10:34:32 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Apr 2024 10:34:32 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <T5BwKtl1gXVDjK2drasP83iF-IwmfSvmTuMOtMBo9bY=.ff192fa8-cd21-4849-877d-6827e72dfc59@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
 <Tp39ngbiUIS96X6n5KWeoLY2M96tAwDHp8X9bovADJQ=.af89e257-4fe7-49f9-b006-070495406d10@github.com>
 <x_m7EhGlHtNjZN1-xoDTkIQY5BSOf278otXsI0A4OzI=.6024316c-a22e-415b-b45d-24c769574cea@github.com>
 <X8woKiKhgvZ9k59V50Q3GUUJ39PW8NmSMUDvyWzVvG4=.9e55080e-8ae3-4570-9fbc-fd2031dc7b3b@github.com>
 <T5BwKtl1gXVDjK2drasP83iF-IwmfSvmTuMOtMBo9bY=.ff192fa8-cd21-4849-877d-6827e72dfc59@github.com>
Message-ID: <2qJchy7CBoHmYdFrUouWsHITBgAmMktmNuy1yXLDCP0=.f38ed4b0-8ec4-4d34-8b3f-a6a92466ebb8@github.com>

On Tue, 23 Apr 2024 10:31:02 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Ok, I got it. And I have updated. But if we want to change `theme` to `long`, then I guess we have to do it every calling function I guess. So is it better to leave it as `Long` ?
>
> I still think we should change `Long` to `long`. Yes, you'll need to update it in the two methods. In `getThemeImpl`, it will be boxed into `Long` automatically before being put into the map.

When the primitive type `long` is used, there's no confusion whether the value can be `null` or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576028406

From aivanov at openjdk.org  Tue Apr 23 10:37:29 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Apr 2024 10:37:29 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v4]
In-Reply-To: <8UHAtnWuQ6QiYqkbd_eU-dCG_6wB5mBC7B7JvQH4do4=.95b041d3-190d-4881-b282-931c33809a6e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <-j3ayhFDO-jCubw1pJmb624osgh4Pv-V3faVcxgQzTE=.b335c713-8882-4931-806d-cea170c5fe06@github.com>
 <yaCIwCbmtgsAf_T3ba8zxS4DmhKooA4vuRMnpTZGaIo=.24140f72-b763-4b00-9767-6ad0c1047708@github.com>
 <8UHAtnWuQ6QiYqkbd_eU-dCG_6wB5mBC7B7JvQH4do4=.95b041d3-190d-4881-b282-931c33809a6e@github.com>
Message-ID: <05mnmxOqOJ9Udnqo8Xfnni0aGUz00kGSUhoBPhTCDw4=.7bac4675-14b0-4d75-861a-273a1ea264df@github.com>

On Tue, 23 Apr 2024 10:30:49 GMT, Tejesh R <tr at openjdk.org> wrote:

>> src/java.desktop/windows/classes/sun/awt/windows/ThemeReader.java line 110:
>> 
>>> 108:            // See documentation for SetWindowTheme on MSDN.
>>> 109:            setWindowTheme(widget.substring(0, i));
>>> 110:            theme = getOpenThemeValue(widget.substring(i + 2), dpi);
>> 
>> I suggest changing the type of `theme` variable from `Long` to `long` as well as the return value of `openThemeImpl`.
>
> Means only till openThemeImpl return value and not further up the hierarchy ?

Yes, only the low-level methods until it's put into a map.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576031141

From tr at openjdk.org  Tue Apr 23 10:41:28 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 10:41:28 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v4]
In-Reply-To: <05mnmxOqOJ9Udnqo8Xfnni0aGUz00kGSUhoBPhTCDw4=.7bac4675-14b0-4d75-861a-273a1ea264df@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <-j3ayhFDO-jCubw1pJmb624osgh4Pv-V3faVcxgQzTE=.b335c713-8882-4931-806d-cea170c5fe06@github.com>
 <yaCIwCbmtgsAf_T3ba8zxS4DmhKooA4vuRMnpTZGaIo=.24140f72-b763-4b00-9767-6ad0c1047708@github.com>
 <8UHAtnWuQ6QiYqkbd_eU-dCG_6wB5mBC7B7JvQH4do4=.95b041d3-190d-4881-b282-931c33809a6e@github.com>
 <05mnmxOqOJ9Udnqo8Xfnni0aGUz00kGSUhoBPhTCDw4=.7bac4675-14b0-4d75-861a-273a1ea264df@github.com>
Message-ID: <1OqvvVJD2qDR6A_vB6sH0Tv12GQMlNmAEGn6gw3a_OY=.a0424d94-d07a-47e1-8d67-929bbd7e67d8@github.com>

On Tue, 23 Apr 2024 10:34:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Means only till openThemeImpl return value and not further up the hierarchy ?
>
> Yes, only the low-level methods until it's put into a map.

Yeah, sounds good. Will do that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18706#discussion_r1576036004

From tr at openjdk.org  Tue Apr 23 10:47:42 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 10:47:42 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v5]
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <LSPKn0ZMyU58ZgMfMCABztGQnrjVMgEEtVPOedHa4jQ=.b956e059-7f40-4dcb-976f-4117a4ad3edf@github.com>

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

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

  Review updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18706/files
  - new: https://git.openjdk.org/jdk/pull/18706/files/9c96cf68..0896dab8

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

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

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

From tr at openjdk.org  Tue Apr 23 11:02:48 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 23 Apr 2024 11:02:48 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v6]
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <_GCjB4NJAF3OxjDPPIHC2OMhy0CWKpKxMgjKbpCFhBI=.1b744369-392a-4140-8dbe-2e4635c9d048@github.com>

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Fixing merge conflicts
 - Review updates
 - Review updates
 - Review updates
 - Moved failure handling inside openThemeImpl method
 - Updated with null check
 - Fix

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

Changes: https://git.openjdk.org/jdk/pull/18706/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18706&range=05
  Stats: 17 lines in 3 files changed: 9 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/18706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18706/head:pull/18706

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

From aivanov at openjdk.org  Tue Apr 23 11:35:31 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Apr 2024 11:35:31 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v6]
In-Reply-To: <_GCjB4NJAF3OxjDPPIHC2OMhy0CWKpKxMgjKbpCFhBI=.1b744369-392a-4140-8dbe-2e4635c9d048@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <_GCjB4NJAF3OxjDPPIHC2OMhy0CWKpKxMgjKbpCFhBI=.1b744369-392a-4140-8dbe-2e4635c9d048@github.com>
Message-ID: <Uh-Z-VRv83hhYYEcGNUoH7TxEeC6hd6qRTgerGwV1OA=.e7600365-769a-4d70-8a9b-d0febab80112@github.com>

On Tue, 23 Apr 2024 11:02:48 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
>> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).
>
> Tejesh R has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - Fixing merge conflicts
>  - Review updates
>  - Review updates
>  - Review updates
>  - Moved failure handling inside openThemeImpl method
>  - Updated with null check
>  - Fix

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18706#pullrequestreview-2016981437

From aivanov at openjdk.org  Tue Apr 23 12:13:29 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Apr 2024 12:13:29 GMT
Subject: RFR: 8322135: javax/swing/JTable/JTableScrollPrintTest.java &
 javax/swing/JTable/PrintAllPagesTest.java throws java.lang.InternalError:
 HTHEME is null [v2]
In-Reply-To: <TTN-J7bXdWpjHVtQeGrj7-E6g0BnsyIGYYZREsJDd00=.ecd61cf3-c728-42e7-8c7c-c68a48fd2095@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
 <ZVdSJfRzlruGocxCRNn-M0MEDjhMwmSlRyCjFp3m1lc=.96e087e1-f862-4c8b-b3a7-1ac28a1c83f5@github.com>
 <NlbDjSlt-lpbkwrBxfn24PhbhDNRH3dgelUKQwq2d80=.0da4ff2e-b1ef-4dd8-9e0d-bcfa032a0de9@github.com>
 <TTN-J7bXdWpjHVtQeGrj7-E6g0BnsyIGYYZREsJDd00=.ecd61cf3-c728-42e7-8c7c-c68a48fd2095@github.com>
Message-ID: <7SZTOtZcTKMACpy__1vuZrcxD1RBF3SKRHst2XKAeC0=.e713fb2d-7b2d-461f-b30a-a099a382346a@github.com>

On Tue, 23 Apr 2024 05:02:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Do you mind if I shorten the subject of the bug? _Printing JTable throws InternalError: HTHEME is null_?
> 
> Sure, it's better to shorten it. And since its only for windows L&F, it can be mentioned in subject I guess.

I've updated the subject to: _Printing JTable in Windows L&F throws InternalError: HTHEME is null_.

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

PR Comment: https://git.openjdk.org/jdk/pull/18706#issuecomment-2072138953

From aivanov at openjdk.org  Tue Apr 23 13:00:35 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 23 Apr 2024 13:00:35 GMT
Subject: Integrated: 8289770: Remove Windows version macro from
 ShellFolder2.cpp
In-Reply-To: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
References: <El-v4mEzaAVWpgYndBI1eFK5EmV7hcOuZDKWTxN_NYU=.ffacd8c7-1313-44b1-b25a-27fd53041ee0@github.com>
Message-ID: <qTIMTGGn33-jMO4Z3qtekiSxxx00mUpHELOUchWnxbE=.0ef68a8f-2b8d-4eb2-a7b0-78fd73fe169e@github.com>

On Thu, 11 Apr 2024 09:33:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This clean-up PR removes unused Windows version macro from `ShellFolder2.cpp`.
> 
> `IS_WINVISTA` was not used at all.
> 
> `IS_WINXP` guarded support for icons with alpha channel. It is now safe to assume Java runs on a Windows version later than Windows XP. Java launchers specify 6.0 as the minimum OS version which corresponds to Windows Vista.

This pull request has now been integrated.

Changeset: 3d5eeac3
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d5eeac3a38ece4a23ea6da2dfe5939d64e81cea
Stats:     18 lines in 1 file changed: 0 ins; 13 del; 5 mod

8289770: Remove Windows version macro from ShellFolder2.cpp

Reviewed-by: jwaters, tr, serb

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

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

From jwaters at openjdk.org  Tue Apr 23 14:00:38 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 23 Apr 2024 14:00:38 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for hsdis
Message-ID: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>

WIP

This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

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

Commit messages:
 - Implementation of hsdis for 8288293: Windows/gcc Port

Changes: https://git.openjdk.org/jdk/pull/18915/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18915&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330988
  Stats: 347 lines in 28 files changed: 161 ins; 22 del; 164 mod
  Patch: https://git.openjdk.org/jdk/pull/18915.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18915/head:pull/18915

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

From ihse at openjdk.org  Tue Apr 23 14:28:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 23 Apr 2024 14:28:31 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

There's a huge amount of changes for just hsdis... You might have to separate out the infrastructure changes that seem to amount to most of the changes here.

This is going to take me a while to get through.

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2072458273

From jwaters at openjdk.org  Tue Apr 23 14:34:27 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 23 Apr 2024 14:34:27 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
 <UtwNIMCOiQMIW52vi4FNfA6Z0r7maxUMA0eOrVmQ2QM=.b0810730-dc5d-4bee-aae3-96b2c8b1c399@github.com>
Message-ID: <gC3MXf8nowx4TzNB4qHTC-fUoC-VTGMRn7EkZqsOLS0=.ab83679d-9b6c-4b86-ae74-3c0c05a44631@github.com>

On Tue, 23 Apr 2024 14:25:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> There's a huge amount of changes for just hsdis... You might have to separate out the infrastructure changes that seem to amount to most of the changes here.
> 
> This is going to take me a while to get through.

Sorry, it's still a WIP, and I believe something broke and scattered changes from one of my other local branches into this current changeset

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2072483937

From jjg at openjdk.org  Tue Apr 23 18:46:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 18:46:34 GMT
Subject: Integrated: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <Hf-QMEmB4eLr-CA0UEIiWRwxxplcD-ZKUVbOJ44BPsc=.20073ab8-4ece-463c-a4e4-afdba6586f28@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This pull request has now been integrated.

Changeset: 9cc163a9
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9cc163a999eb8e9597d45b095b642c25071043bd
Stats:     134 lines in 23 files changed: 50 ins; 56 del; 28 mod

8330178: Clean up non-standard use of /** comments in `java.base`

Reviewed-by: darcy, iris, dfuchs, aivanov, naoto

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

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

From jjg at openjdk.org  Tue Apr 23 20:26:57 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 20:26:57 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v7]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <RHregxT5ye-XTQEWzPqLPVZXgm2Id82FV--QqNLAJMc=.4c5c4e64-3a6c-438f-a877-e6f9689986fd@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=06
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From ihse at openjdk.org  Wed Apr 24 09:17:28 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 24 Apr 2024 09:17:28 GMT
Subject: RFR: 8330988: Implementation of 8288293: Windows/gcc Port for
 hsdis
In-Reply-To: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
References: <bXwOUFPBZUWDmidfDnVJLBKG4HkeS585IJqAOK8W1ys=.211183fe-b18e-498d-a557-6e6c4dfac27c@github.com>
Message-ID: <usSjNoHaMLDK2yN1CVz7X91uSIbpQslnD0hBtTFtnsw=.e7b4dede-07bf-41af-bef1-02672ef4758d@github.com>

On Tue, 23 Apr 2024 13:56:32 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> WIP
> 
> This changeset contains hsdis for Windows/gcc Port. It supports both the binutils and capstone backends, though the LLVM backend is left out due to compatibility issues encountered during the build. Currently, which gcc distributions are supported is still to be clarified, as several, ranging from Cygwin, to MinGW64, to the gcc subsystems from MSYS2. For this reason, the build system hack in place at the moment to compile the binutils backend on Windows is still left in place, for now.

Please mark the PR as draft it is not intended for review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18915#issuecomment-2074481887

From magnus.ihse.bursie at oracle.com  Wed Apr 24 11:24:32 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 24 Apr 2024 13:24:32 +0200
Subject: Usage of iconv()
In-Reply-To: <20240423121114.EE241662C87@dd33810.kasserver.com>
References: <20240423121114.EE241662C87@dd33810.kasserver.com>
Message-ID: <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>

That is a good question. libiconv is used only on macOS and AIX, for a 
few libraries, as you say. I just tried removing -liconv from the macOS 
dependencies and recompiled, just to see what would happen. There were 
three instances for macOS: libsplashscreen, libjdwp and libinstrument.

Out of these, libinstrument compiled and linked fine without the -liconv 
argument. It looks like iconv is referenced in 
unix/.../EncodingSupport_md.c, but otoh it looks like it is as much (or 
as little) referenced on macOS as on linux (where we never have linked 
with -liconv) so it is perhaps just dead code. I did not study it in 
detail. The code looks very much duplicated from libjdwp.

The other two actually failed linking, so they do use libiconv.

libsplashscreen uses it in splashscreen_sys.m, where it is used to 
convert the jar file name.

libjdwp uses it in utf_util.c, where it is used to convert file name and 
command lines, iiuc.

It is likely that we have similar (but better) ways to convert charsets 
elsewhere in our libraries that can be used instead of libiconv. I guess 
these are not the only two places where a filename must be converted 
from the platform charset to UTF8.

/Magnus

On 2024-04-23 14:11, Bernd Eckenfels wrote:
> Du to a glibc security alert about a charset in iconv() I checked OpenJDK (since I was quite sure encoding is handled in JCL), however there are a few utilities (related to libinstrument and splash Screens) which use iconv.
>
> If I see it correctly it?s mostly used for utf8 so it should not expose this particular globe weakness, but I still wonder if that dependency is needed. For some platforms like AIX it even drags on an additional library dependency. (Not to mention different charger tables and especially ugly locale dependencies for containers).
>
> Gru?
> Bernd
> ?
> https://bernd.eckenfels.net

From pminborg at openjdk.org  Wed Apr 24 12:00:58 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 24 Apr 2024 12:00:58 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v7]
In-Reply-To: <YqMHwwkz2Lezr2Mvaav4QLyOAaO1OrjMCq8R3nhBpdA=.6ad77975-989f-42eb-9644-f3b576b68f00@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
 <lj7O4Bv1QYMArWAyHkuzZ8zbXQ7mj2WF7b_fDEt8hpk=.e22d8bb2-5dc3-4f8a-b4e1-261aab5c8b00@github.com>
 <YqMHwwkz2Lezr2Mvaav4QLyOAaO1OrjMCq8R3nhBpdA=.6ad77975-989f-42eb-9644-f3b576b68f00@github.com>
Message-ID: <BIdnoOqZEAdovGv_MHq69c-Woe2IUEeMuXdcVbB7rK4=.6ba4fd05-f162-473c-8a49-74b26a51d427@github.com>

On Mon, 22 Apr 2024 13:46:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Simplify tests
>>  - Add a test for null arg
>>  - Add a test for findOrThrow()
>>  - Merge branch 'master' into symbol-lookup-findorthrow
>>  - Change exception type
>>  - Update src/java.base/share/classes/java/lang/foreign/package-info.java
>>    
>>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>>  - Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>>    
>>    Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
>>  - Fix typo
>>  - Update after PR comments
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/099a64e8...0e06e0d6
>
> test/jdk/java/foreign/loaderLookup/TestSymbolLookupFindOrThrow.java line 41:
> 
>> 39: 
>> 40:     static {
>> 41:         System.loadLibrary("Foo");
> 
> Where is this lib defined?

it is defined in the sub-folder `lookup` in the file `libFoo.c`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18474#discussion_r1577755855

From pminborg at openjdk.org  Wed Apr 24 12:00:55 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 24 Apr 2024 12:00:55 GMT
Subject: RFR: 8314592: Add shortcut to SymbolLookup::find [v8]
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <pPLDryemgOYiiTFVA0-bkRUKQaHhfS0V0wFJrZcXS1E=.2756273a-3b5d-47da-b732-a6136f82a12c@github.com>

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

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

  Remove redundant test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18474/files
  - new: https://git.openjdk.org/jdk/pull/18474/files/0e06e0d6..31d92589

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

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

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

From pminborg at openjdk.org  Wed Apr 24 12:00:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 24 Apr 2024 12:00:59 GMT
Subject: Integrated: 8314592: Add shortcut to SymbolLookup::find
In-Reply-To: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
References: <WVW1qJmVoiZsdz9o_obJRkBUzRpIl58L7eLXzC4iJIs=.34b25ae5-7098-4459-986d-4223fc5b49ab@github.com>
Message-ID: <bk3WBv4WulMnN77g5mkOQyS-2cOiugC00NKt6oUQr2E=.053e25c8-7bbe-4f9c-935b-189664448965@github.com>

On Mon, 25 Mar 2024 14:56:23 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> While `SymbolLookup` correctly uses an `Optional` return to denote whether a symbol has been found by the lookup or not (which enables composition of symbol lookups), many clients end up just calling `Optional::get`, or `Optional::orElseThrow()` on the result.
> 
> This PR proposes to add a convenience method `SymbolLookup::findOrThrow` that will do a lookup and, if no symbol can be found, throws an `IllegalArgumentException` with a relevant exception message.

This pull request has now been integrated.

Changeset: e923dfe4
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e923dfe4c51291099d9b7411e6c9f20be79b9a53
Stats:     151 lines in 22 files changed: 88 ins; 0 del; 63 mod

8314592: Add shortcut to SymbolLookup::find

Reviewed-by: jvernee, prr

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

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

From prr at openjdk.org  Wed Apr 24 17:56:33 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 24 Apr 2024 17:56:33 GMT
Subject: Integrated: 8328896: Fontmetrics for large Fonts has zero width
In-Reply-To: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
References: <weFfLpOEq1wDbJkG1VYraKaf7JArDvUOZ8wSbU-UtiE=.85281826-0474-435c-9b91-29fe62b1bb5e@github.com>
Message-ID: <tx6-EoGWMzGcAHTVgKl38XMY4fIYxbc2DVjmK2aY3tM=.c9e9be6a-96df-4bef-90dd-18c5e64dc563@github.com>

On Tue, 9 Apr 2024 18:50:17 GMT, Phil Race <prr at openjdk.org> wrote:

> The main problem here is that we do not curate what font point size we passed to freetype,
> and would pass in one larger than freetype's maximum of FT_USHORT_MAX which is USHRT_MAX.
> This isn't documented, SFAICS, and is checked a couple of calls deep from the specific API we use.
> But generally anywhere near that size seems to cause freetype to choke as it uses signed 16.16
> values, so 32767 is really the max.
> But we have no need to go anywhere near that - 16384 seems like a plenty large enough pt size.
> And we can request bigger sizes than that by making use of the transform.
> At normal size ranges we use that just to account for rotation and decompose the glyph transform
> into point size and that rotation.
> 
> But at large sizes - which are not usefully rendered anyway - there are no hints etc to be lost
> from not specifying the target point size. So we can extend the range of sizes we allow.
> 
> If  this is still too large to be held decomposed into a pt size in the range less than 16384 and a scale of up to 32766 then we substitute the null scaler, as we generally do when values are out of range, such
> a for a NaN transform.
> 
> These extreme values aren't useful.
> 
> In looking at this I did find that getGlyphPixelBounds doesn't follow the maximum image size we use
> for rendering. Which is not useful and could lead to inconsistent results. I fixed that.
> 
> Also whilst macOS didn't have these problems it could be cleaned up a bit for consistency in the reported sizes for some cases.
> 
> The test is mainly around making sure that "sensible" things are returned for not sensible input.
> There's no 100% right answer to these extreme unrenderable sizes.

This pull request has now been integrated.

Changeset: 25871af3
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25871af36b1397bdc3715ab0edc589f0483ea0b1
Stats:     166 lines in 5 files changed: 164 ins; 0 del; 2 mod

8328896: Fontmetrics for large Fonts has zero width

Reviewed-by: tr, serb

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

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

From kizune at openjdk.org  Wed Apr 24 22:02:28 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Wed, 24 Apr 2024 22:02:28 GMT
Subject: RFR: 8323965: modify fix for 8317771 to remove reflection
 instantiation of the inner class
In-Reply-To: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
References: <2vGEkGcBtrR_dYGworNL5on_il3hWfyfdwFjcB7Z3Ac=.56952b99-040a-41ec-8c89-3309597d8b6e@github.com>
Message-ID: <ay7UtGQk-qMzPGE0YzdFDom5vGyA55RDwVO95lP6nZU=.cdf02b83-9c6b-4c19-88ae-10aa679b6070@github.com>

On Fri, 19 Apr 2024 15:16:41 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> I replaced reflection with using an accessor
> @azuev-java please review

src/java.desktop/share/classes/javax/swing/JTree.java line 4276:

> 4274: 
> 4275:         static {
> 4276:             SwingAccessor.setAccessibleJTreeNodeCreateAccessor(new AccessibleTreNodeACreateccessor());

I think there is a typo here. AccessibleTreNodeACreateccessor does not sound right. Should be AccessibleTreeNodeCreateAccessor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18867#discussion_r1578567536

From tr at openjdk.org  Thu Apr 25 04:34:36 2024
From: tr at openjdk.org (Tejesh R)
Date: Thu, 25 Apr 2024 04:34:36 GMT
Subject: Integrated: 8322135: Printing JTable in Windows L&F throws
 InternalError: HTHEME is null
In-Reply-To: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
References: <wWPGF-14rgWCAvLaN0iXcio4FML-5mtfqhL9VtUQQLg=.0cb28f41-1592-4fcd-b808-210e3377ea0e@github.com>
Message-ID: <aQCWWJqHEDCB6O6QKvohJDrVrgpyrezYbMLEJE5LHBk=.50744eef-205d-403c-b1b0-dc0b9995eb8b@github.com>

On Wed, 10 Apr 2024 04:32:53 GMT, Tejesh R <tr at openjdk.org> wrote:

> Getting a theme for particular dpi failed in windows L&F during print test. Before [JDK-8294427](https://bugs.openjdk.org/browse/JDK-8294427) fix, theme was independent of DPI. After the fix (https://github.com/openjdk/jdk/commit/a63afa4aa62863d1a199a0fb7d2f56ff8fcd04fd) getting a theme in Windows L&F became dependent on DPI. Now it works fine in paint to a frame or window but for printing the DPI is computed with scaling factor which might not be w.r.t set of connected monitors and hence error is returned according to [this from windows document](https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi). 
> The suggested fix is to handle printer cases with default dpi since in error condition 0 is returned with `openThemeImpl(widget, dpi)`. The fix seems to be working fine without causing any regression (Tested in CI systems and also the affected tests).

This pull request has now been integrated.

Changeset: 21480a7a
Author:    Tejesh R <tr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21480a7ae8dce67cf3a844d8caafb0b96c37ac0e
Stats:     17 lines in 3 files changed: 9 ins; 0 del; 8 mod

8322135: Printing JTable in Windows L&F throws InternalError: HTHEME is null

Reviewed-by: abhiscxk, honkar, aivanov

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

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

From abhiscxk at openjdk.org  Thu Apr 25 10:24:30 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Thu, 25 Apr 2024 10:24:30 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected [v2]
In-Reply-To: <Kq8Gv5_G7yMscWPJEQ8XQaDyEq5ppUW8RE47c1QNIgE=.0d2fd125-e544-47bf-a4ee-c03a8f0cd5fb@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
 <Kq8Gv5_G7yMscWPJEQ8XQaDyEq5ppUW8RE47c1QNIgE=.0d2fd125-e544-47bf-a4ee-c03a8f0cd5fb@github.com>
Message-ID: <tcK_IrbV7_Jpf4VIqelNHhhulZP01K2VN7Y8VqLhE8E=.f5d32017-35f5-46cf-a766-b975652adcb8@github.com>

On Tue, 23 Apr 2024 07:51:59 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Instructions set has been updated as per OS specific. JTable keyboard navigation is tested in each OS and according it's current implementation the instructions has been updated (Few has been removed and few has been updated). 
>> PassFailJFrame.builder is used.
>
> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review updates

Default time out may not be sufficient to test, can be increased.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 198:

> 196:         final String WINDOWS_SPECIFIC = """
> 197:                 Tab, Shift-Tab - Navigate In.
> 198:                 Return/Shift-Return - move focus one cell down/up.

Suggestion:

                Return/Shift-Return - Move focus one cell down/up.

For consistency please ensure each command action to start with either lower case or upper case. Same for F2, Esc commands etc.

Check for Linux and Mac specific instructions also.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 202:

> 200:                 Up/Down Arrow - deselect current selection; move focus one
> 201:                                 cell up/down
> 202:                 Left/Right Arrow - deselect current selection; move focus

Seems the instruction needs to modify.
On press of Left/Right arrow, only focus shifted to one cell left or right but the current row selection remains same.

Similar for Home/End as well, current selection remains as it is.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 217:

> 215:                 F2 - Allows editing in a cell containing information without
> 216:                      overwriting the information
> 217:                 Esc -  Resets the cell content back to the state it was in

Suggestion:

                Esc -  Reset the cell content back to the state it was in.


Minor suggestion,  end with `.` for each statement else nothing.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 220:

> 218:                        before editing started
> 219:                 Ctrl+A, Ctrl+/ - Select All
> 220:                 Ctrl+\\ - De-select all

Suggestion:

                Ctrl+\\ - deselect all

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 222:

> 220:                 Ctrl+\\ - De-select all
> 221:                 Shift-Up/Down Arrow -  extend selection up/down one row
> 222:                 Shift-Left/Right Arrow - extend selection left/right one

No extended selection of columns only focus changed from one cell to another.

test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 226:

> 224:                 Control-shift Up/Down Arrow -  extend selection to top/bottom
> 225:                                                 of column
> 226:                 Shift-Home/End -  extend selection to left/right end of row

No extended selection only focus shifted to first and last column.

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

PR Review: https://git.openjdk.org/jdk/pull/18855#pullrequestreview-2022085343
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1579228099
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1579218399
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1579221288
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1579231419
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1579219557
PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1579220991

From azvegint at openjdk.org  Thu Apr 25 11:57:35 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 25 Apr 2024 11:57:35 GMT
Subject: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager
Message-ID: <6hNTGt36hX3KFH6r1Vi-kDV0fd2_C9kLP6k69G36HMg=.214a2c22-d4c5-4714-a992-492d54b761ef@github.com>

This fix adds missing doPrivileged calls in TokenStorage, which is used to help take screenshots in Wayland.

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

Commit messages:
 - initial

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

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

From aivanov at openjdk.org  Thu Apr 25 16:48:48 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 25 Apr 2024 16:48:48 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
Message-ID: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>

This PR provides a regression test for [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in BasicDirectoryModel.validateFileCache_ reviewed in #18111.

The test is inspired and based on `ConcurrentModification` that I wrote for [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670).

**How the test works**

The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.

The test starts several scanner threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.

The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by `SNAPSHOTS` constant.)

The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created.

The test fails consistently without the fix for JDK-8325179. On Windows, the output looks like this:


Number of snapshots: 20
Number of snapshots where number of loader threads:
  = 1: 0
  = 2: 0
  > 2: 20
java.lang.RuntimeException: Detected 20 snapshots with several loading threads
        at LoaderThreadCount.runTest(LoaderThreadCount.java:132)
        at LoaderThreadCount.wrapper(LoaderThreadCount.java:72)
        at java.base/java.lang.Thread.run(Thread.java:1583)


On Linux and macOS, there's more variation, for example I got the following output on one of Linux systems:


Number of snapshots: 15
Number of snapshots where number of loader threads:
  = 1: 7
  = 2: 2
  > 2: 6


The test passes on the builds where JDK-8325179 is present.

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

Commit messages:
 - Add copyright header; ensure headless mode (for macOS)
 - Merge master
 - Remove printing number of loader threads in each snapshot
 - Add comments to clarify how thread snapshots are captured
 - Use > 2 condition for error case
 - Add a test for JDK-8325179: count FilesLoader threads

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

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

From aivanov at openjdk.org  Thu Apr 25 16:48:48 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 25 Apr 2024 16:48:48 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
In-Reply-To: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
Message-ID: <HIbA2S-_3OkKYSnU7RXa3C3YY2W-iqb2rY8vDygxs98=.78744488-ac8a-4256-b368-86111e4e0ae2@github.com>

On Thu, 25 Apr 2024 16:37:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This PR provides a regression test for [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in BasicDirectoryModel.validateFileCache_ reviewed in #18111.
> 
> The test is inspired and based on `ConcurrentModification` that I wrote for [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670).
> 
> **How the test works**
> 
> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
> 
> The test starts several scanner threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
> 
> The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by `SNAPSHOTS` constant.)
> 
> The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created.
> 
> The test fails consistently without the fix for JDK-8325179. On Windows, the output looks like this:
> 
> 
> Number of snapshots: 20
> Number of snapshots where number of loader threads:
>   = 1: 0
>   = 2: 0
>   > 2: 20
> java.lang.RuntimeException: Detected 20 snapshots with several loading threads
>         at LoaderThreadCount.runTest(LoaderThreadCount.java:132)
>         at LoaderThreadCount.wrapper(LoaderThreadCount.java:72)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> On Linux and macOS, there's more variation, for example I got the following output on one of Linux systems:
> 
> 
> Number of snapshots: 15
> Number of snapshots where number of loader threads:
>   = 1: 7
>   = 2: 2
>   > 2: 6
> 
> 
> The test passes on the builds where JDK-8325179 is present.

Could you, @mrserb and @TejeshR13, take a look? You reviewed the test for [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670) in #18109.

Those who reviewed [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179) in #18111 ? @prrace and @turbanoff ? could be interested too.

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

PR Comment: https://git.openjdk.org/jdk/pull/18957#issuecomment-2077726248

From azvegint at openjdk.org  Thu Apr 25 17:22:48 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 25 Apr 2024 17:22:48 GMT
Subject: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager
 [v2]
In-Reply-To: <6hNTGt36hX3KFH6r1Vi-kDV0fd2_C9kLP6k69G36HMg=.214a2c22-d4c5-4714-a992-492d54b761ef@github.com>
References: <6hNTGt36hX3KFH6r1Vi-kDV0fd2_C9kLP6k69G36HMg=.214a2c22-d4c5-4714-a992-492d54b761ef@github.com>
Message-ID: <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>

> This fix adds missing doPrivileged calls in TokenStorage, which is used to help take screenshots in Wayland.

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

  fix copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18950/files
  - new: https://git.openjdk.org/jdk/pull/18950/files/5da7e9bf..73f21b6b

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

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

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

From philip.race at oracle.com  Thu Apr 25 18:30:43 2024
From: philip.race at oracle.com (Philip Race)
Date: Thu, 25 Apr 2024 11:30:43 -0700
Subject: Usage of iconv()
In-Reply-To: <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>
References: <20240423121114.EE241662C87@dd33810.kasserver.com>
 <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>
Message-ID: <91874482-df68-4e76-99e9-4fb90ef2c7a7@oracle.com>



On 4/24/24 4:24 AM, Magnus Ihse Bursie wrote:
> That is a good question. libiconv is used only on macOS and AIX, for a 
> few libraries, as you say. I just tried removing -liconv from the 
> macOS dependencies and recompiled, just to see what would happen. 
> There were three instances for macOS: libsplashscreen, libjdwp and 
> libinstrument.
>
>
>
> libsplashscreen uses it in splashscreen_sys.m, where it is used to 
> convert the jar file name.

This is called from the launcher, in java.base/share/native/libjli/java.c


>
> libjdwp uses it in utf_util.c, where it is used to convert file name 
> and command lines, iiuc.
>
> It is likely that we have similar (but better) ways to convert 
> charsets elsewhere in our libraries that can be used instead of 
> libiconv. I guess these are not the only two places where a filename 
> must be converted from the platform charset to UTF8.

So whatever replacement there might be, it needs to be something that is 
available very early in the life of the VM, in fact before there is a VM 
running.

-phil.

From prr at openjdk.org  Thu Apr 25 18:45:40 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Apr 2024 18:45:40 GMT
Subject: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager
 [v2]
In-Reply-To: <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>
References: <6hNTGt36hX3KFH6r1Vi-kDV0fd2_C9kLP6k69G36HMg=.214a2c22-d4c5-4714-a992-492d54b761ef@github.com>
 <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>
Message-ID: <sx67FEKHvfvnYfRD9RscAoltfgr5YAtuE3DYiBca1uE=.6e98400d-78d7-43ee-9416-7bd2702a02b6@github.com>

On Thu, 25 Apr 2024 17:22:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix adds missing doPrivileged calls in TokenStorage, which is used to help take screenshots in Wayland.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright years

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18950#pullrequestreview-2023323765

From honkar at openjdk.org  Thu Apr 25 22:34:59 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 25 Apr 2024 22:34:59 GMT
Subject: RFR: JDK-8329004 : Update Libpng to 1.6.43
Message-ID: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>

Libpng updated from 1.6.40 to  1.6.43

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

Commit messages:
 - .md file update
 - libpng update v1.6.43

Changes: https://git.openjdk.org/jdk/pull/18964/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18964&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329004
  Stats: 694 lines in 23 files changed: 258 ins; 205 del; 231 mod
  Patch: https://git.openjdk.org/jdk/pull/18964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18964/head:pull/18964

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

From prr at openjdk.org  Thu Apr 25 22:49:35 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 25 Apr 2024 22:49:35 GMT
Subject: RFR: JDK-8329004 : Update Libpng to 1.6.43
In-Reply-To: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
References: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
Message-ID: <ro-l2-eW5FhoYip8YarFhZHQv9Vj5Efifb9vQBIlYRw=.20fe7d17-285f-4fe9-a1ec-66f60ccebc1a@github.com>

On Thu, 25 Apr 2024 22:28:06 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Libpng updated from 1.6.40 to  1.6.43

src/java.desktop/share/native/libsplashscreen/libpng/png.h line 30:

> 28:  * License version 2 only, as published by the Free Software Foundation.
> 29:  * However, the following notice accompanied the original version of this
> 30:  * file and, per its terms, should not be removed:

You have lost the above 4 lines from every source file you updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18964#discussion_r1580217289

From jjg at openjdk.org  Thu Apr 25 22:53:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 22:53:04 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v8]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <l0Wf7Ng-zjDRAZwhsOY9wf2dytL6ctdsMmLCL3tkgdc=.670a964c-af86-4c75-9d5a-4f6e479ac598@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

Jonathan Gibbons has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments # Please enter a commit message to explain why this merge is necessary, # especially if it merges an updated upstream into a topic branch. # # Lines starting with '#' will be ignored, and an empty message aborts # the
   commit.
 - Merge with upstream/master
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - Merge with upstream/master
 - update test
 - improve handling of ignorable doc comments
   suppress warning when building test code
 - Merge remote-tracking branch 'upstream/master' into 8303689.dangling-comments
 - call `saveDanglingDocComments` for local variable declarations
 - adjust call for `saveDanglingDocComments` for enum members
 - ... and 1 more: https://git.openjdk.org/jdk/compare/1c238d43...16a265a2

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

Changes: https://git.openjdk.org/jdk/pull/18527/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=07
  Stats: 485 lines in 59 files changed: 387 ins; 3 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/18527.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527

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

From honkar at openjdk.org  Thu Apr 25 23:14:59 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 25 Apr 2024 23:14:59 GMT
Subject: RFR: JDK-8329004 : Update Libpng to 1.6.43 [v2]
In-Reply-To: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
References: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
Message-ID: <3HGuh53DhduViIAAF32QXR_ZXvxJB4McWcE6MonDyDE=.be78c170-ed5f-4e4b-936a-c6224618f09f@github.com>

> Libpng updated from 1.6.40 to  1.6.43

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

  added missing 4 lines of header

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18964/files
  - new: https://git.openjdk.org/jdk/pull/18964/files/229f88f1..f9021883

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

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

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

From honkar at openjdk.org  Thu Apr 25 23:15:00 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 25 Apr 2024 23:15:00 GMT
Subject: RFR: JDK-8329004 : Update Libpng to 1.6.43 [v2]
In-Reply-To: <ro-l2-eW5FhoYip8YarFhZHQv9Vj5Efifb9vQBIlYRw=.20fe7d17-285f-4fe9-a1ec-66f60ccebc1a@github.com>
References: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
 <ro-l2-eW5FhoYip8YarFhZHQv9Vj5Efifb9vQBIlYRw=.20fe7d17-285f-4fe9-a1ec-66f60ccebc1a@github.com>
Message-ID: <_aMPoeHwdbLG5mP2L26xeTbUbwoDevx0SMowKo_5tgo=.6dd0e1cd-3820-4bd5-b077-8cf32b67b583@github.com>

On Thu, 25 Apr 2024 22:46:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added missing 4 lines of header
>
> src/java.desktop/share/native/libsplashscreen/libpng/png.h line 30:
> 
>> 28:  * License version 2 only, as published by the Free Software Foundation.
>> 29:  * However, the following notice accompanied the original version of this
>> 30:  * file and, per its terms, should not be removed:
> 
> You have lost the above 4 lines from every source file you updated.

Thanks for catching it Phil.
Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18964#discussion_r1580239651

From honkar at openjdk.org  Thu Apr 25 23:17:59 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 25 Apr 2024 23:17:59 GMT
Subject: RFR: JDK-8329004 : Update Libpng to 1.6.43 [v3]
In-Reply-To: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
References: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
Message-ID: <NmWPciakd4x-FfaPuBbmTeAG-eCP-8Q0KG0WP_9EIxA=.8b2a30b6-b3bd-4ea5-bdfc-75e60174b62f@github.com>

> Libpng updated from 1.6.40 to  1.6.43

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

  Updating.txt

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18964/files
  - new: https://git.openjdk.org/jdk/pull/18964/files/f9021883..ad038006

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

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

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

From jjg at openjdk.org  Thu Apr 25 23:24:07 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 25 Apr 2024 23:24:07 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  revert need to disable warning

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/16a265a2..39689a52

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

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

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

From vromero at openjdk.org  Fri Apr 26 00:23:33 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 26 Apr 2024 00:23:33 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v9]
In-Reply-To: <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <be6kTtJezTLou_YPTgclvACoddoyffmpupwBjO2DIT8=.6cab77e8-c42a-4e22-9bcb-a8fea5cebf67@github.com>
Message-ID: <txquEDIJ7YBKTZ6-EggzWEHSYzFxMXIBbwTuexdYXro=.af5bb232-dbd4-4099-9fc7-3bc22aacdd07@github.com>

On Thu, 25 Apr 2024 23:24:07 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert need to disable warning

looks good

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 583:

> 581:      *     dangling comments are also attached to the tree node
> 582:      *     by registering them using the {@link #deferredLintHandler}.
> 583:      *  5. (Later) Warnings may be genereated for the dangling

typo: generated

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2023792395
PR Review Comment: https://git.openjdk.org/jdk/pull/18527#discussion_r1580263826

From serb at openjdk.org  Fri Apr 26 02:36:32 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 26 Apr 2024 02:36:32 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
In-Reply-To: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
Message-ID: <aY1yliqjnoXlLkiEnV6jFyVL6niEpXCxvMmns98gxwQ=.86362fec-648a-41e3-b514-d73e867a3858@github.com>

On Thu, 25 Apr 2024 16:37:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This PR provides a regression test for [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in BasicDirectoryModel.validateFileCache_ reviewed in #18111.
> 
> The test is inspired and based on `ConcurrentModification` that I wrote for [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670).
> 
> **How the test works**
> 
> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
> 
> The test starts several scanner threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
> 
> The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by `SNAPSHOTS` constant.)
> 
> The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created.
> 
> The test fails consistently without the fix for JDK-8325179. On Windows, the output looks like this:
> 
> 
> Number of snapshots: 20
> Number of snapshots where number of loader threads:
>   = 1: 0
>   = 2: 0
>   > 2: 20
> java.lang.RuntimeException: Detected 20 snapshots with several loading threads
>         at LoaderThreadCount.runTest(LoaderThreadCount.java:132)
>         at LoaderThreadCount.wrapper(LoaderThreadCount.java:72)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> On Linux and macOS, there's more variation, for example I got the following output on one of Linux systems:
> 
> 
> Number of snapshots: 15
> Number of snapshots where number of loader threads:
>   = 1: 7
>   = 2: 2
>   > 2: 6
> 
> 
> The test passes on the builds where JDK-8325179 is present.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18957#pullrequestreview-2024039392

From mickleness at gmail.com  Fri Apr 26 02:52:48 2024
From: mickleness at gmail.com (Jeremy Wood)
Date: Fri, 26 Apr 2024 02:52:48 +0000
Subject: Question about coalescing COMPONENT_RESIZED events
Message-ID: <em8e21e86b-ffb5-404c-a8c9-034885e75e26@505df37e.com>

I?m looking for general feedback/advice.

Is there any reason not to put the following method in a Component?

@Override
protected AWTEvent coalesceEvents(AWTEvent existingEvent, AWTEvent 
newEvent) {
     if (newEvent.getID() == ComponentEvent.COMPONENT_RESIZED)
         return newEvent;
     return super.coalesceEvents(existingEvent, newEvent);
}

(That is: is this unsafe/unwise for some reason I?m not considering?)

As I understand it: when you resize a window every call to 
component#setBounds(..) generates a new ComponentEvent and posts it to 
the event queue. So suppose you resized a window so its height was 10, 
then 11, then 12, then 13, then 14: that would create 5 ComponentEvents 
and post them to the event queue.

So suppose you also have this listener:

myComponent.addComponentListener(new ComponentAdapter() {
     public void componentResized(ComponentEvent e) {
         System.out.println(e.getComponent().getHeight());
     }
});

Your output in this scenario may be 10, 11, 12, 13, 14 if you have a 
very responsive EDT. But it could also be 14, 14, 14, 14, 14. The only 
guarantee is that the last printed height of the 5 ComponentEvents will 
be 14.

So if the ComponentEvents come in all at once: there?s no harm in 
coalescing them, right? (So now you may get anywhere from 1 to 5 
ComponentEvents, but each call to e.getComponent().getSize() will 
produce a different result.)

Regards,
  - Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20240426/0f552254/attachment-0001.htm>

From jjg at openjdk.org  Fri Apr 26 16:04:09 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 16:04:09 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

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

  fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18527/files
  - new: https://git.openjdk.org/jdk/pull/18527/files/39689a52..48e8b0a2

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

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

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

From achung at openjdk.org  Fri Apr 26 18:54:04 2024
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 26 Apr 2024 18:54:04 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
Message-ID: <1tmchNL8jbX76-dk-YWH6o8jxWswiNkTXcY-AMvFEkQ=.97119056-2fbe-4aa5-a7d1-698091a6dfbb@github.com>

Updating giflib, clientlibs tests are green on all platforms

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

Commit messages:
 - revert tab spacing to spaces
 - init commit

Changes: https://git.openjdk.org/jdk/pull/18956/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328999
  Stats: 823 lines in 7 files changed: 159 ins; 105 del; 559 mod
  Patch: https://git.openjdk.org/jdk/pull/18956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18956/head:pull/18956

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

From prr at openjdk.org  Fri Apr 26 19:27:54 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 19:27:54 GMT
Subject: RFR: JDK-8329004 : Update Libpng to 1.6.43 [v3]
In-Reply-To: <NmWPciakd4x-FfaPuBbmTeAG-eCP-8Q0KG0WP_9EIxA=.8b2a30b6-b3bd-4ea5-bdfc-75e60174b62f@github.com>
References: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
 <NmWPciakd4x-FfaPuBbmTeAG-eCP-8Q0KG0WP_9EIxA=.8b2a30b6-b3bd-4ea5-bdfc-75e60174b62f@github.com>
Message-ID: <mXnv51EdWThi17IC8NNtenkrMkYEr3KcfNrqrb8wprQ=.a1998a51-5990-4180-9678-22cc61a27fef@github.com>

On Thu, 25 Apr 2024 23:17:59 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Libpng updated from 1.6.40 to  1.6.43
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating.txt

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18964#pullrequestreview-2025736301

From prr at openjdk.org  Fri Apr 26 19:32:49 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 19:32:49 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <1tmchNL8jbX76-dk-YWH6o8jxWswiNkTXcY-AMvFEkQ=.97119056-2fbe-4aa5-a7d1-698091a6dfbb@github.com>
References: <1tmchNL8jbX76-dk-YWH6o8jxWswiNkTXcY-AMvFEkQ=.97119056-2fbe-4aa5-a7d1-698091a6dfbb@github.com>
Message-ID: <9GjNJGAl-hA1qEgsowgETn-3R9uhcfPtyxpVI-ZdZ98=.88601d7a-43c1-47fe-8424-62b406136561@github.com>

On Thu, 25 Apr 2024 16:26:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updating giflib, clientlibs tests are green on all platforms

Why don't I see an updated giflib.md ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18956#issuecomment-2080005026

From prr at openjdk.org  Fri Apr 26 19:34:00 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 19:34:00 GMT
Subject: RFR: 8303689: javac -Xlint could/should report on "dangling" doc
 comments [v10]
In-Reply-To: <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
 <WA4RKekV8mLqnrxi1HqfCR2F6DT27mqVdLhigmerCtA=.33dcb72a-f3ff-4d9a-a794-95ff3849e5fa@github.com>
Message-ID: <SD0S716mdRSViTfaViQgFYEkmR7WmBalQQe3_FI7VQc=.b83407a8-0c84-4ed9-8b56-adf6db1a2e0c@github.com>

On Fri, 26 Apr 2024 16:04:09 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
>> 
>> The work can be thought of as in 3 parts:
>> 
>> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
>> 
>> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
>> 
>>      *  Dangling documentation comments are handled as follows.
>>      *  1. {@code Scanner} adds all doc comments to a queue of
>>      *     recent doc comments. The queue is flushed whenever
>>      *     it is known that the recent doc comments should be
>>      *     ignored and should not cause any warnings.
>>      *  2. The primary documentation comment is the one obtained
>>      *     from the first token of any declaration.
>>      *     (using {@code token.getDocComment()}.
>>      *  3. At the end of the "signature" of the declaration
>>      *     (that is, before any initialization or body for the
>>      *     declaration) any other "recent" comments are saved
>>      *     in a map using the primary comment as a key,
>>      *     using this method, {@code saveDanglingComments}.
>>      *  4. When the tree node for the declaration is finally
>>      *     available, and the primary comment, if any,
>>      *     is "attached", (in {@link #attach}) any related
>>      *     dangling comments are also attached to the tree node
>>      *     by registering them using the {@link #deferredLintHandler}.
>>      *  5. (Later) Warnings may be genereated for the dangling
>>      *     comments, subject to the {@code -Xlint} and
>>      *     {@code @SuppressWarnings}.
>> 
>> 
>> 3.  Updates to the make files to disable the warnings in modules for which the 
>> warning is generated.  This is often because of the confusing use of `/**` to
>> create box or other standout comments.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18527#pullrequestreview-2025744069

From jjg at openjdk.org  Fri Apr 26 19:49:56 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 26 Apr 2024 19:49:56 GMT
Subject: Integrated: 8303689: javac -Xlint could/should report on "dangling"
 doc comments
In-Reply-To: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
References: <T_hVB24wAdfq2M4bC_BxfHPjdB_-uF6w3QyRvcgW7vQ=.309824a7-d67c-4619-9862-017fae5521d4@github.com>
Message-ID: <jz5iSs8rS6B9ZP2l3HbT7UR9gdQiXvxyQFGqikRLN7U=.584799e9-55c0-4a22-b62f-e30406cfe8ea@github.com>

On Wed, 27 Mar 2024 22:04:30 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option.
> 
> The work can be thought of as in 3 parts:
> 
> 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not.
> 
> 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`.  The procedure for handling dangling doc comments is described in this comment in `JavacParser`.
> 
>      *  Dangling documentation comments are handled as follows.
>      *  1. {@code Scanner} adds all doc comments to a queue of
>      *     recent doc comments. The queue is flushed whenever
>      *     it is known that the recent doc comments should be
>      *     ignored and should not cause any warnings.
>      *  2. The primary documentation comment is the one obtained
>      *     from the first token of any declaration.
>      *     (using {@code token.getDocComment()}.
>      *  3. At the end of the "signature" of the declaration
>      *     (that is, before any initialization or body for the
>      *     declaration) any other "recent" comments are saved
>      *     in a map using the primary comment as a key,
>      *     using this method, {@code saveDanglingComments}.
>      *  4. When the tree node for the declaration is finally
>      *     available, and the primary comment, if any,
>      *     is "attached", (in {@link #attach}) any related
>      *     dangling comments are also attached to the tree node
>      *     by registering them using the {@link #deferredLintHandler}.
>      *  5. (Later) Warnings may be genereated for the dangling
>      *     comments, subject to the {@code -Xlint} and
>      *     {@code @SuppressWarnings}.
> 
> 
> 3.  Updates to the make files to disable the warnings in modules for which the 
> warning is generated.  This is often because of the confusing use of `/**` to
> create box or other standout comments.

This pull request has now been integrated.

Changeset: a920af23
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a920af233a11592af113f456f7608cb59dd1617e
Stats:     482 lines in 58 files changed: 385 ins; 3 del; 94 mod

8303689: javac -Xlint could/should report on "dangling" doc comments

Reviewed-by: vromero, ihse, prr

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

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

From dnguyen at openjdk.org  Fri Apr 26 19:53:50 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 26 Apr 2024 19:53:50 GMT
Subject: RFR: JDK-8329004 : Update Libpng to 1.6.43 [v3]
In-Reply-To: <NmWPciakd4x-FfaPuBbmTeAG-eCP-8Q0KG0WP_9EIxA=.8b2a30b6-b3bd-4ea5-bdfc-75e60174b62f@github.com>
References: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
 <NmWPciakd4x-FfaPuBbmTeAG-eCP-8Q0KG0WP_9EIxA=.8b2a30b6-b3bd-4ea5-bdfc-75e60174b62f@github.com>
Message-ID: <4Dyfs5ezyL0umuMeAOnq4bEawpotwi2jDmobEmlUd4s=.3a88acf9-bf3b-476c-9fe1-491ca8bec2b5@github.com>

On Thu, 25 Apr 2024 23:17:59 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Libpng updated from 1.6.40 to  1.6.43
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating.txt

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18964#pullrequestreview-2025770176

From achung at openjdk.org  Fri Apr 26 20:28:47 2024
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 26 Apr 2024 20:28:47 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <9GjNJGAl-hA1qEgsowgETn-3R9uhcfPtyxpVI-ZdZ98=.88601d7a-43c1-47fe-8424-62b406136561@github.com>
References: <1tmchNL8jbX76-dk-YWH6o8jxWswiNkTXcY-AMvFEkQ=.97119056-2fbe-4aa5-a7d1-698091a6dfbb@github.com>
 <9GjNJGAl-hA1qEgsowgETn-3R9uhcfPtyxpVI-ZdZ98=.88601d7a-43c1-47fe-8424-62b406136561@github.com>
Message-ID: <aGHoNEezk4ePhJ_F6_4o449FzM8P-BVgLaeFIF-5lXs=.da08e572-9a1d-4eba-af46-5c49c4762aa4@github.com>

On Fri, 26 Apr 2024 19:30:25 GMT, Phil Race <prr at openjdk.org> wrote:

> Why don't I see an updated giflib.md ?

The md file is still in the process of being approved by legal

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

PR Comment: https://git.openjdk.org/jdk/pull/18956#issuecomment-2080072668

From prr at openjdk.org  Fri Apr 26 20:39:48 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 20:39:48 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <aGHoNEezk4ePhJ_F6_4o449FzM8P-BVgLaeFIF-5lXs=.da08e572-9a1d-4eba-af46-5c49c4762aa4@github.com>
References: <1tmchNL8jbX76-dk-YWH6o8jxWswiNkTXcY-AMvFEkQ=.97119056-2fbe-4aa5-a7d1-698091a6dfbb@github.com>
 <9GjNJGAl-hA1qEgsowgETn-3R9uhcfPtyxpVI-ZdZ98=.88601d7a-43c1-47fe-8424-62b406136561@github.com>
 <aGHoNEezk4ePhJ_F6_4o449FzM8P-BVgLaeFIF-5lXs=.da08e572-9a1d-4eba-af46-5c49c4762aa4@github.com>
Message-ID: <EYFEIibb7yqw8nfQmRr4zhcJDkogwv-ZGEFql251uNQ=.396f65a5-fc35-4e11-a5e1-9a7840122983@github.com>

On Fri, 26 Apr 2024 20:26:14 GMT, Alisen Chung <achung at openjdk.org> wrote:

> > Why don't I see an updated giflib.md ?
> 
> The md file is still in the process of being approved by legal

So the PR should be reverted to draft until everything is ready.

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

PR Comment: https://git.openjdk.org/jdk/pull/18956#issuecomment-2080085069

From achung at openjdk.org  Fri Apr 26 21:39:00 2024
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 26 Apr 2024 21:39:00 GMT
Subject: Withdrawn: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <1tmchNL8jbX76-dk-YWH6o8jxWswiNkTXcY-AMvFEkQ=.97119056-2fbe-4aa5-a7d1-698091a6dfbb@github.com>
References: <1tmchNL8jbX76-dk-YWH6o8jxWswiNkTXcY-AMvFEkQ=.97119056-2fbe-4aa5-a7d1-698091a6dfbb@github.com>
Message-ID: <oaISbVZp53g59fGgsqXzzloWZ-eWOIc0QbmRGwZLYJ0=.108e66f2-53d3-4943-b506-730a1b1631f9@github.com>

On Thu, 25 Apr 2024 16:26:49 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updating giflib, clientlibs tests are green on all platforms

This pull request has been closed without being integrated.

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

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

From achung at openjdk.org  Fri Apr 26 21:42:09 2024
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 26 Apr 2024 21:42:09 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
Message-ID: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>

Updating giflib, clientlibs tests are green on all platforms

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

Commit messages:
 - update md
 - revert tab spacing to spaces
 - init commit

Changes: https://git.openjdk.org/jdk/pull/18985/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18985&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328999
  Stats: 846 lines in 8 files changed: 179 ins; 105 del; 562 mod
  Patch: https://git.openjdk.org/jdk/pull/18985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18985/head:pull/18985

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

From prr at openjdk.org  Fri Apr 26 22:24:31 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 26 Apr 2024 22:24:31 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
References: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
Message-ID: <T2xdTHoXHvkRf8L7XH4yPPOYu7aAbkFK0E0hXzcBP-o=.3b9844c7-c2ac-4581-b8ec-e045d59fa59e@github.com>

On Fri, 26 Apr 2024 21:37:56 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updating giflib, clientlibs tests are green on all platforms

This giflib update has huge amount of gratuitous reformatting make it hard to spot what is really new.
I hope they don't repeat that.

src/java.desktop/share/native/libsplashscreen/giflib/gif_hash.h line 40:

> 38: #include <unistd.h>
> 39: #endif
> 40: /** End JDK modifications to support building on Windows **/

Do we still need this ?

src/java.desktop/share/native/libsplashscreen/giflib/gif_lib.h line 57:

> 55: #define true 1
> 56: /** End JDK modifications to support building using old compilers**/
> 57: 

Do we still need this ?

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

PR Comment: https://git.openjdk.org/jdk/pull/18985#issuecomment-2080172718
PR Review Comment: https://git.openjdk.org/jdk/pull/18985#discussion_r1581575163
PR Review Comment: https://git.openjdk.org/jdk/pull/18985#discussion_r1581574254

From duke at openjdk.org  Sun Apr 28 15:48:15 2024
From: duke at openjdk.org (=?UTF-8?B?5p+z6bKy6bmP?=)
Date: Sun, 28 Apr 2024 15:48:15 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: <1EA9-JQlwrdPer0LbuYYpDXaEraY89J4LMzFwNmjKc4=.55b4cb99-428b-4a51-a339-304dd33d001f@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

I am back now. Who can check and merge this code?

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

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2081525688

From abhiscxk at openjdk.org  Mon Apr 29 09:06:18 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 29 Apr 2024 09:06:18 GMT
Subject: RFR: 8155030: The Menu Mnemonics are always displayed for GTK LAF
Message-ID: <ljL8Jp1AmzQLAdJ9pX67plhCglF9oREnckUsPjfMrrU=.8ed74af3-41c5-493d-8d73-dd9b88ecbaf4@github.com>

In GTK LAF, the menu mnemonics are always displayed which is different from the native behavior. In native application **(tested with gedit**), the menu mnemonics toggle on press of `ALT` key. Menu mnemonics are hidden initially and then toggles between show/hide on `ALT` press. 
Proposed fix is to handle the `ALT` key press for GTK LAF and mimic the native behavior. Fix is similar to the `ALT` key processing in  Windows LAF. Automated test case is added to verify the fix and tested in Ubuntu and Oracle linux.

CI testing was green and link attached in JBS.

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

Commit messages:
 - Mnemonic toggle fix

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

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

From tr at openjdk.org  Mon Apr 29 10:45:04 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 29 Apr 2024 10:45:04 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
In-Reply-To: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
Message-ID: <ecwX2L-D-PYsgCyIFAiPcC3P-ak7swNBEaVKRnfNggc=.53d754f4-14a6-4f56-8658-63a3c7018dd9@github.com>

On Thu, 25 Apr 2024 16:37:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This PR provides a regression test for [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in BasicDirectoryModel.validateFileCache_ reviewed in #18111.
> 
> The test is inspired and based on `ConcurrentModification` that I wrote for [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670).
> 
> **How the test works**
> 
> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
> 
> The test starts several scanner threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
> 
> The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by `SNAPSHOTS` constant.)
> 
> The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created.
> 
> The test fails consistently without the fix for JDK-8325179. On Windows, the output looks like this:
> 
> 
> Number of snapshots: 20
> Number of snapshots where number of loader threads:
>   = 1: 0
>   = 2: 0
>   > 2: 20
> java.lang.RuntimeException: Detected 20 snapshots with several loading threads
>         at LoaderThreadCount.runTest(LoaderThreadCount.java:132)
>         at LoaderThreadCount.wrapper(LoaderThreadCount.java:72)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> On Linux and macOS, there's more variation, for example I got the following output on one of Linux systems:
> 
> 
> Number of snapshots: 15
> Number of snapshots where number of loader threads:
>   = 1: 7
>   = 2: 2
>   > 2: 6
> 
> 
> The test passes on the builds where JDK-8325179 is present.

Is it necessary to create dummy files here in this test? Can't we just create JFileChooser without creating dummy files and proceed with loader test? Because I tested without using dummy files and getting exception without JDK-8325179 fix.

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

PR Review: https://git.openjdk.org/jdk/pull/18957#pullrequestreview-2028095745

From azvegint at openjdk.org  Mon Apr 29 10:50:25 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 29 Apr 2024 10:50:25 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test failures
Message-ID: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>

Some tests try to get the focus of a window by clicking on its title bar.

On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.

So the solution is to click inside the window or call `toFront()` to get the window focused.

Some tests have problems with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.

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

Commit messages:
 - initial

Changes: https://git.openjdk.org/jdk/pull/18995/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18995&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8280988
  Stats: 239 lines in 5 files changed: 125 ins; 45 del; 69 mod
  Patch: https://git.openjdk.org/jdk/pull/18995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18995/head:pull/18995

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

From azvegint at openjdk.org  Mon Apr 29 10:50:25 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 29 Apr 2024 10:50:25 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures
In-Reply-To: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
Message-ID: <q0eAS2qZ-hkNtEs9Q1mY7ES2EcAbJj2-ktbl1hJASs4=.3b36a548-97e2-4b5d-9f2b-ecddfdbd7a85@github.com>

On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Some tests try to get the focus of a window by clicking on its title bar.
> 
> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
> 
> So the solution is to click inside the window or call `toFront()` to get the window focused.
> 
> Some tests have problems with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.

test/jdk/java/awt/Focus/ModalDialogInFocusEventTest.java line 25:

> 23: 
> 24: /*
> 25:   @test

For some reason, this test was not enabled when it was open sourced, so enable it.
Testing is green on all platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1582855462

From duke at openjdk.org  Mon Apr 29 12:47:11 2024
From: duke at openjdk.org (Joel Uckelman)
Date: Mon, 29 Apr 2024 12:47:11 GMT
Subject: RFR: 8305072: Win32ShellFolder2.compareTo is inconsistent [v2]
In-Reply-To: <21db5CiFTVN7scwsIHknMxF4YaVQd06m7gUOhcCLvMI=.e2f61ea7-bf9a-4632-bf45-c89f979ae806@github.com>
References: <bEiHvkFnBZDqmiqQdk_-_mATVhDbAD7NZX7VnkHLG2E=.27ee84ba-00fd-405a-9489-8fe11c215af9@github.com>
 <21db5CiFTVN7scwsIHknMxF4YaVQd06m7gUOhcCLvMI=.e2f61ea7-bf9a-4632-bf45-c89f979ae806@github.com>
Message-ID: <kxS0TvCNVk6nioHYJVuySli0sTLx7vSCSIdbucpHfMU=.acc830b1-4d90-4088-b013-5789f6373385@github.com>

On Tue, 5 Mar 2024 17:40:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> The implementation of `Win32ShellFolder2.compareTo` is inconsistent: there are cases where  
>> `a < b & b < c but a == c`  
>> which *violates its general contract*.
>> 
>> In particular, it happens for the personal folder (*Documents*) if it is listed *twice*: as a special and as a regular folder.
>> 
>> The evaluation performed by the submitter of the bug provided enough details to create a test, reproduce the problem and finally resolve it.
>> 
>> Without the fix, the regression test always fails:
>> 
>> a < b & b < c but a >= c
>> where
>>   a = C:\Users<user>\Documents(true)
>>   b = C:\Users<user>(false)
>>   c = C:\Users<user>\Documents(false)
>> 
>> as well as for the reverse case: `a > b & b > c`.
>> 
>> How it is possible to have the same folder in a list of files twice remains unknown. I believe it is another bug in JDK, however, no one has been able to reproduce it so far.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Handle fakePersonal on Windows 10
>   
>   The desktop folder on Windows 10 does not include
>   the Personal (Documents) folder.

Will this be backported to Java 21 and 22? It would be very helpful if it could be.

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

PR Comment: https://git.openjdk.org/jdk/pull/18126#issuecomment-2082632924

From aivanov at openjdk.org  Mon Apr 29 13:14:11 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 29 Apr 2024 13:14:11 GMT
Subject: RFR: 8305072: Win32ShellFolder2.compareTo is inconsistent [v2]
In-Reply-To: <kxS0TvCNVk6nioHYJVuySli0sTLx7vSCSIdbucpHfMU=.acc830b1-4d90-4088-b013-5789f6373385@github.com>
References: <bEiHvkFnBZDqmiqQdk_-_mATVhDbAD7NZX7VnkHLG2E=.27ee84ba-00fd-405a-9489-8fe11c215af9@github.com>
 <21db5CiFTVN7scwsIHknMxF4YaVQd06m7gUOhcCLvMI=.e2f61ea7-bf9a-4632-bf45-c89f979ae806@github.com>
 <kxS0TvCNVk6nioHYJVuySli0sTLx7vSCSIdbucpHfMU=.acc830b1-4d90-4088-b013-5789f6373385@github.com>
Message-ID: <xjHWQrkgvyMZBN6yQY_m_zoXL_mAl4ZN14JozrqjiM8=.d7db986e-a733-427c-a5af-c3ec930dbbb5@github.com>

On Mon, 29 Apr 2024 12:44:14 GMT, Joel Uckelman <duke at openjdk.org> wrote:

> Will this be backported to Java 21 and 22? It would be very helpful if it could be.

It is already backported to 22.
I'm working on backporting it to all supported Oracle releases of Java. It is up to the OpenJDK community to backport the changeset into OpenJDK-based releases.

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

PR Comment: https://git.openjdk.org/jdk/pull/18126#issuecomment-2082703443

From aivanov at openjdk.org  Mon Apr 29 13:25:06 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 29 Apr 2024 13:25:06 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
In-Reply-To: <ecwX2L-D-PYsgCyIFAiPcC3P-ak7swNBEaVKRnfNggc=.53d754f4-14a6-4f56-8658-63a3c7018dd9@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
 <ecwX2L-D-PYsgCyIFAiPcC3P-ak7swNBEaVKRnfNggc=.53d754f4-14a6-4f56-8658-63a3c7018dd9@github.com>
Message-ID: <U9y6alR1KPG2nUHO5Utq4lof-3kek8XgvomsU4dK88A=.c674f5ad-0c93-4b31-94e2-7c25ba6e32c9@github.com>

On Mon, 29 Apr 2024 10:42:26 GMT, Tejesh R <tr at openjdk.org> wrote:

> Is it necessary to create dummy files here in this test? Can't we just create JFileChooser without creating dummy files and proceed with loader test? Because I tested without using dummy files and getting exception without JDK-8325179 fix.

Yes, it is necessary to create the dummy files. The background threads need to run for a while; if there are no files, the threads may complete before the snapshot is created.

Windows is usually less affected because all scanning on Windows is serialized via the COM thread. Linux and macOS aren't stable enough without the files. Even with the files, in one of the runs on Linux, there were only 4 snapshots which contained the File Loader threads. That is 4 out of 20 snapshots taken. Without the files and with less files, the test could pass where it should fail.

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

PR Comment: https://git.openjdk.org/jdk/pull/18957#issuecomment-2082732906

From tr at openjdk.org  Mon Apr 29 14:48:06 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 29 Apr 2024 14:48:06 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
In-Reply-To: <U9y6alR1KPG2nUHO5Utq4lof-3kek8XgvomsU4dK88A=.c674f5ad-0c93-4b31-94e2-7c25ba6e32c9@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
 <ecwX2L-D-PYsgCyIFAiPcC3P-ak7swNBEaVKRnfNggc=.53d754f4-14a6-4f56-8658-63a3c7018dd9@github.com>
 <U9y6alR1KPG2nUHO5Utq4lof-3kek8XgvomsU4dK88A=.c674f5ad-0c93-4b31-94e2-7c25ba6e32c9@github.com>
Message-ID: <BiNHDM1CJPFfidmtzV3WqwcbKUADmznQExi8D2NpP00=.83e1a628-acce-43cf-9525-ffb341c22196@github.com>

On Mon, 29 Apr 2024 13:22:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > Is it necessary to create dummy files here in this test? Can't we just create JFileChooser without creating dummy files and proceed with loader test? Because I tested without using dummy files and getting exception without JDK-8325179 fix.
> 
> Yes, it is necessary to create the dummy files. The background threads need to run for a while; if there are no files, the threads may complete before the snapshot is created.
> 
> Windows is usually less affected because all scanning on Windows is serialized via the COM thread. Linux and macOS aren't stable enough without the files. Even with the files, in one of the runs on Linux, there were only 4 snapshots which contained the File Loader threads. That is 4 out of 20 snapshots taken. Without the files and with less files, the test could pass where it should fail.

Yeah, my observation was w.r.t windows. Will have to test in Linux then.

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

PR Comment: https://git.openjdk.org/jdk/pull/18957#issuecomment-2082940642

From vdyakov at openjdk.org  Mon Apr 29 15:52:06 2024
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Mon, 29 Apr 2024 15:52:06 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures
In-Reply-To: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
Message-ID: <AMoJ0Aza9ysZ0pMgCw1oHVDnYbG14E44OXMZ3TsGFdc=.e0443b34-4754-4f00-8274-555712c57223@github.com>

On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Some tests try to get the focus of a window by clicking on its title bar.
> 
> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
> 
> So the solution is to click inside the window or call `toFront()` to get the window focused.
> 
> Some tests have problems with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.

@honkar-jdk @prrace please review

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

PR Comment: https://git.openjdk.org/jdk/pull/18995#issuecomment-2083087917

From honkar at openjdk.org  Mon Apr 29 16:31:10 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 29 Apr 2024 16:31:10 GMT
Subject: Integrated: JDK-8329004 : Update Libpng to 1.6.43
In-Reply-To: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
References: <BTpLIG1WsAYuAixtJWOSKTCi2l0jBDPJxVAY75930v0=.7750eec3-a52d-42ad-9fec-45abe236e170@github.com>
Message-ID: <oinxHaaOsev73vB3-V__xeEUYwgxD81L4-knFwtl4X4=.f07b34f1-54a4-48e4-aaff-bc66b3840ea7@github.com>

On Thu, 25 Apr 2024 22:28:06 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> Libpng updated from 1.6.40 to  1.6.43

This pull request has now been integrated.

Changeset: 4e422943
Author:    Harshitha Onkar <honkar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e4229438ad2e8ac59ac675465e4d3d4e13bf156
Stats:     610 lines in 18 files changed: 258 ins; 120 del; 232 mod

8329004: Update Libpng to 1.6.43

Reviewed-by: prr, dnguyen

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

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

From tr at openjdk.org  Mon Apr 29 17:03:08 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 29 Apr 2024 17:03:08 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
In-Reply-To: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
Message-ID: <yth_AZ39lPyHIe3VqVgw99lgScDPm6NGt883ucUKvmc=.50b8e16c-e1c5-4f16-b89b-9f282d21e58f@github.com>

On Thu, 25 Apr 2024 16:37:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> This PR provides a regression test for [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in BasicDirectoryModel.validateFileCache_ reviewed in #18111.
> 
> The test is inspired and based on `ConcurrentModification` that I wrote for [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670).
> 
> **How the test works**
> 
> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
> 
> The test starts several scanner threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
> 
> The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by `SNAPSHOTS` constant.)
> 
> The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created.
> 
> The test fails consistently without the fix for JDK-8325179. On Windows, the output looks like this:
> 
> 
> Number of snapshots: 20
> Number of snapshots where number of loader threads:
>   = 1: 0
>   = 2: 0
>   > 2: 20
> java.lang.RuntimeException: Detected 20 snapshots with several loading threads
>         at LoaderThreadCount.runTest(LoaderThreadCount.java:132)
>         at LoaderThreadCount.wrapper(LoaderThreadCount.java:72)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> On Linux and macOS, there's more variation, for example I got the following output on one of Linux systems:
> 
> 
> Number of snapshots: 15
> Number of snapshots where number of loader threads:
>   = 1: 7
>   = 2: 2
>   > 2: 6
> 
> 
> The test passes on the builds where JDK-8325179 is present.

Marked as reviewed by tr (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18957#pullrequestreview-2029067659

From tr at openjdk.org  Mon Apr 29 17:03:09 2024
From: tr at openjdk.org (Tejesh R)
Date: Mon, 29 Apr 2024 17:03:09 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel
In-Reply-To: <BiNHDM1CJPFfidmtzV3WqwcbKUADmznQExi8D2NpP00=.83e1a628-acce-43cf-9525-ffb341c22196@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
 <ecwX2L-D-PYsgCyIFAiPcC3P-ak7swNBEaVKRnfNggc=.53d754f4-14a6-4f56-8658-63a3c7018dd9@github.com>
 <U9y6alR1KPG2nUHO5Utq4lof-3kek8XgvomsU4dK88A=.c674f5ad-0c93-4b31-94e2-7c25ba6e32c9@github.com>
 <BiNHDM1CJPFfidmtzV3WqwcbKUADmznQExi8D2NpP00=.83e1a628-acce-43cf-9525-ffb341c22196@github.com>
Message-ID: <UOpOj_WlSa38QHzGmvQGg2VZiwSgDj3nd_5o7yv2IZ8=.4d11109a-2e2b-4eed-8089-4672adcd8392@github.com>

On Mon, 29 Apr 2024 14:45:43 GMT, Tejesh R <tr at openjdk.org> wrote:

> > Is it necessary to create dummy files here in this test? Can't we just create JFileChooser without creating dummy files and proceed with loader test? Because I tested without using dummy files and getting exception without JDK-8325179 fix.
> 
> Yes, it is necessary to create the dummy files. The background threads need to run for a while; if there are no files, the threads may complete before the snapshot is created.
> 
> Windows is usually less affected because all scanning on Windows is serialized via the COM thread. Linux and macOS aren't stable enough without the files. Even with the files, in one of the runs on Linux, there were only 4 snapshots which contained the File Loader threads. That is 4 out of 20 snapshots taken. Without the files and with less files, the test could pass where it should fail.

You are right, failure is unpredictable in linux unlike in Windows.  Test looks good to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/18957#issuecomment-2083225265

From aivanov at openjdk.org  Mon Apr 29 19:59:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 29 Apr 2024 19:59:18 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel [v2]
In-Reply-To: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
Message-ID: <B_-OHAIBsbdBoUv4pQoe39sU8WgY94Y9pmHAhPQ0a4E=.5a5d96e9-d964-4c62-ad39-a279c4afd61c@github.com>

> This PR provides a regression test for [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in BasicDirectoryModel.validateFileCache_ reviewed in #18111.
> 
> The test is inspired and based on `ConcurrentModification` that I wrote for [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670).
> 
> **How the test works**
> 
> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
> 
> The test starts several scanner threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
> 
> The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by `SNAPSHOTS` constant.)
> 
> The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created.
> 
> The test fails consistently without the fix for JDK-8325179. On Windows, the output looks like this:
> 
> 
> Number of snapshots: 20
> Number of snapshots where number of loader threads:
>   = 1: 0
>   = 2: 0
>   > 2: 20
> java.lang.RuntimeException: Detected 20 snapshots with several loading threads
>         at LoaderThreadCount.runTest(LoaderThreadCount.java:132)
>         at LoaderThreadCount.wrapper(LoaderThreadCount.java:72)
>         at java.base/java.lang.Thread.run(Thread.java:1583)
> 
> 
> On Linux and macOS, there's more variation, for example I got the following output on one of Linux systems:
> 
> 
> Number of snapshots: 15
> Number of snapshots where number of loader threads:
>   = 1: 7
>   = 2: 2
>   > 2: 6
> 
> 
> The test passes on the builds where JDK-8325179 is present.

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

  Suppress throwing exceptions while deleting files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18957/files
  - new: https://git.openjdk.org/jdk/pull/18957/files/49723a37..16136976

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

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

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

From honkar at openjdk.org  Mon Apr 29 20:43:05 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 29 Apr 2024 20:43:05 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures
In-Reply-To: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
Message-ID: <QyUBNaT1lr9By3R1AN0UhUN60sqro-9Jx2LIODL9OB8=.4402b34d-a3e0-4c0b-aac9-c73ab731fa33@github.com>

On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Some tests try to get the focus of a window by clicking on its title bar.
> 
> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
> 
> So the solution is to click inside the window or call `toFront()` to get the window focused.
> 
> Some tests have issues with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.

Tested on Ubuntu 23.04. Changes look good.

test/jdk/java/awt/Focus/ModalDialogInFocusEventTest.java line 29:

> 27:   @summary Showing modal dialog during dispatching SequencedEvent
> 28:   @key headful
> 29:   @run main ModalDialogInFocusEventTest

Minor: Better to have the `@key` tag after `@test`.

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18995#pullrequestreview-2029591268
PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1583728864

From azvegint at openjdk.org  Mon Apr 29 21:08:06 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 29 Apr 2024 21:08:06 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <T2xdTHoXHvkRf8L7XH4yPPOYu7aAbkFK0E0hXzcBP-o=.3b9844c7-c2ac-4581-b8ec-e045d59fa59e@github.com>
References: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
 <T2xdTHoXHvkRf8L7XH4yPPOYu7aAbkFK0E0hXzcBP-o=.3b9844c7-c2ac-4581-b8ec-e045d59fa59e@github.com>
Message-ID: <ShC4W1cAwrda_a5g_4xErxsnM93Q9v-MRx9aZRw4D7s=.99209477-4e6e-4b10-87be-885b5fa0dae9@github.com>

On Fri, 26 Apr 2024 22:02:38 GMT, Phil Race <prr at openjdk.org> wrote:

>> Updating giflib, clientlibs tests are green on all platforms
>
> src/java.desktop/share/native/libsplashscreen/giflib/gif_hash.h line 40:
> 
>> 38: #include <unistd.h>
>> 39: #endif
>> 40: /** End JDK modifications to support building on Windows **/
> 
> Do we still need this ?

The GIFLIB version 5.2.2 adds the `ifndef` wrap, so it looks like our comment can be removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18985#discussion_r1583770021

From honkar at openjdk.org  Mon Apr 29 21:13:04 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 29 Apr 2024 21:13:04 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures
In-Reply-To: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
Message-ID: <X-jAvGhyEUX6RK5o4QNHemdIXsLD5Fes9Mn2kbgssdE=.7536c02c-80af-4927-b1b9-58fd32643d52@github.com>

On Mon, 29 Apr 2024 10:44:37 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Some tests try to get the focus of a window by clicking on its title bar.
> 
> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
> 
> So the solution is to click inside the window or call `toFront()` to get the window focused.
> 
> Some tests have issues with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.

test/jdk/java/awt/regtesthelpers/Util.java line 674:

> 672:         return System.getenv("WAYLAND_DISPLAY") != null;
> 673:     }
> 674: 

Is it better to have this function in `jdk/test/lib/Platform.java` since all the other OS-related checks are in Platform.java ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1583774219

From honkar at openjdk.org  Mon Apr 29 23:29:11 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 29 Apr 2024 23:29:11 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions
Message-ID: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>

For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

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

Commit messages:
 - minor update
 - added instructions for clarity

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

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

From honkar at openjdk.org  Tue Apr 30 00:32:15 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 00:32:15 GMT
Subject: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager
 [v2]
In-Reply-To: <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>
References: <6hNTGt36hX3KFH6r1Vi-kDV0fd2_C9kLP6k69G36HMg=.214a2c22-d4c5-4714-a992-492d54b761ef@github.com>
 <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>
Message-ID: <FR_kLYhcIR602FlT4xXJC7yagTW1Mcu2s-10TMq1Wws=.a3aecf35-7146-4a1e-b9b4-f45590ae15a9@github.com>

On Thu, 25 Apr 2024 17:22:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix adds missing doPrivileged calls in TokenStorage, which is used to help take screenshots in Wayland.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright years

LGTM

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

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18950#pullrequestreview-2029970599

From azvegint at openjdk.org  Tue Apr 30 02:02:30 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 30 Apr 2024 02:02:30 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures [v2]
In-Reply-To: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
Message-ID: <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>

> Some tests try to get the focus of a window by clicking on its title bar.
> 
> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
> 
> So the solution is to click inside the window or call `toFront()` to get the window focused.
> 
> Some tests have issues with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.

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

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18995/files
  - new: https://git.openjdk.org/jdk/pull/18995/files/c2f63151..ef4d7716

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

  Stats: 39 lines in 6 files changed: 15 ins; 12 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/18995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18995/head:pull/18995

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

From azvegint at openjdk.org  Tue Apr 30 02:08:11 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 30 Apr 2024 02:08:11 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures [v2]
In-Reply-To: <X-jAvGhyEUX6RK5o4QNHemdIXsLD5Fes9Mn2kbgssdE=.7536c02c-80af-4927-b1b9-58fd32643d52@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
 <X-jAvGhyEUX6RK5o4QNHemdIXsLD5Fes9Mn2kbgssdE=.7536c02c-80af-4927-b1b9-58fd32643d52@github.com>
Message-ID: <TOd2O7W6Kr5ccMrDdd4JVLshZloamiDw9zbA2vdRIHY=.b518b638-c7d6-404f-968d-c90df09a6894@github.com>

On Mon, 29 Apr 2024 21:08:28 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> test/jdk/java/awt/regtesthelpers/Util.java line 674:
> 
>> 672:         return System.getenv("WAYLAND_DISPLAY") != null;
>> 673:     }
>> 674: 
> 
> Is it better to have this function in `jdk/test/lib/Platform.java` since all the other OS-related checks are in Platform.java ?

Yes, that sounds right to me. Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1584031430

From azvegint at openjdk.org  Tue Apr 30 02:08:10 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 30 Apr 2024 02:08:10 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures [v2]
In-Reply-To: <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
 <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>
Message-ID: <-g8ymb6jvkKlHW1-ibdAduToYe-C9UpdTX9mxGLWbpg=.5d61c983-5d12-44d5-8ca4-dc5513fd8e6b@github.com>

On Tue, 30 Apr 2024 02:02:30 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Some tests try to get the focus of a window by clicking on its title bar.
>> 
>> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
>> 
>> So the solution is to click inside the window or call `toFront()` to get the window focused.
>> 
>> Some tests have issues with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

test/jdk/java/awt/Focus/ModalDialogInFocusEventTest.java line 29:

> 27:   @bug 4531693 4636269 4681908 4688142 4691646 4721470
> 28:   @summary Showing modal dialog during dispatching SequencedEvent
> 29:   @run main ModalDialogInFocusEventTest

This test can be run standalone (`java ...`), so I prefer to keep it that way, so I didn't add the usage of `Platform.isOnWayland`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1584032165

From abhiscxk at openjdk.org  Tue Apr 30 04:31:06 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 30 Apr 2024 04:31:06 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions
In-Reply-To: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
Message-ID: <Br5PF0pWBfV_9LtdRTn4kj4s9eIEqid57msiJp3ZtDQ=.530240c0-50f4-4308-9a9b-8408e98eaa57@github.com>

On Mon, 29 Apr 2024 23:24:19 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

Since these lines are unchanged, can't add comments there.

1. AT L155, space after `=` is missing.
`icontst =new CreateFrame(cbIconState.getState(), cbResize.getState());`

2. In `CreateFrame` constructor, calling `pack()` is redundant as frame size is set by `setBounds(...)` method.

3. L24 to L31 may be removed. Consolidated summary can be defined in `jtreg summary tag`.

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 91:

> 89: 
> 90:         Do the above steps for all the different Frame state combinations available.<br>
> 91:         For "hide,iconify and show" case, the frame is hidden then iconified hence Window2

Minor: 
Suggestion:

        For "hide, iconify and show" case, the frame is hidden then iconified hence Window2

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 94:

> 92:         is not seen on-screen when shown as the frame is still in the ICONIFIED state.
> 93:         Window2 is visible on-screen when it is restored to NORMAL state as observed with
> 94:         "hide,iconify,show and restore" case.<br><br>

Suggestion:

        "hide, iconify, show and restore" case.<br><br>

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 112:

> 110:     CheckboxGroup cbgState = new CheckboxGroup();
> 111:     CheckboxGroup cbgResize = new CheckboxGroup();
> 112:     Checkbox cbIconState = new Checkbox("Frame state ICONIFIED", cbgState, true);

Suggestion:

    Checkbox cbIconState = new Checkbox("Frame State ICONIFIED", cbgState, true);


How about capitalize each word for Checkbox text ?

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 122:

> 120:         PassFailJFrame
> 121:                 .builder()
> 122:                 .title("GetBoundsResizeTest Instructions")

Looks like title is mismatched with the test. Should it be "Frame State and Size Test Instructions" ?

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 326:

> 324:         public void stateLog(String message) {
> 325:             PassFailJFrame
> 326:                 .log("[Current State=%d] %s %s".formatted(getState(), name, message));

Suggestion:

                .log("[Current State = %d] %s %s".formatted(getState(), name, message));

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 330:

> 328: 
> 329:         public void stateLog() {
> 330:             PassFailJFrame.log("[Current State=" + getState() + "]");

Suggestion:

            PassFailJFrame.log("[Current State = " + getState() + "]");

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

PR Review: https://git.openjdk.org/jdk/pull/19008#pullrequestreview-2030155210
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584104123
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584104632
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584098207
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584116502
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584106094
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584106363

From serb at openjdk.org  Tue Apr 30 05:50:05 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Apr 2024 05:50:05 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures [v2]
In-Reply-To: <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
 <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>
Message-ID: <bX30-_5tlMtvAFXkOmzXyguGcfBkSwm86lz_rGlNRxA=.1944ec74-bf02-4ebf-ba88-e3680e9f1ef9@github.com>

On Tue, 30 Apr 2024 02:02:30 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Some tests try to get the focus of a window by clicking on its title bar.
>> 
>> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
>> 
>> So the solution is to click inside the window or call `toFront()` to get the window focused.
>> 
>> Some tests have issues with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

test/jdk/java/awt/Focus/6981400/Test1.java line 186:

> 184:         Util.clickOnComp(compToClick, robot);
> 185: 
> 186:         if (Platform.isOnWayland()) {

If the goal is just to move the window to the front then can we try "toFront + click on title" on X11 and just "toFront" on Wayland?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1584163903

From serb at openjdk.org  Tue Apr 30 05:57:05 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Apr 2024 05:57:05 GMT
Subject: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager
 [v2]
In-Reply-To: <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>
References: <6hNTGt36hX3KFH6r1Vi-kDV0fd2_C9kLP6k69G36HMg=.214a2c22-d4c5-4714-a992-492d54b761ef@github.com>
 <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>
Message-ID: <C9yiRaMrn2xaUyKYG99jEoCnBKKukxcX44JqpVgRQZM=.65b47bf9-1821-4f0b-9083-c6e9669d1732@github.com>

On Thu, 25 Apr 2024 17:22:48 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This fix adds missing doPrivileged calls in TokenStorage, which is used to help take screenshots in Wayland.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright years

How hard is it to create a new test for this issue?

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

PR Comment: https://git.openjdk.org/jdk/pull/18950#issuecomment-2084434625

From azvegint at openjdk.org  Tue Apr 30 07:57:05 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 30 Apr 2024 07:57:05 GMT
Subject: RFR: 8331011: [XWayland] TokenStorage fails under Security Manager
 [v2]
In-Reply-To: <C9yiRaMrn2xaUyKYG99jEoCnBKKukxcX44JqpVgRQZM=.65b47bf9-1821-4f0b-9083-c6e9669d1732@github.com>
References: <6hNTGt36hX3KFH6r1Vi-kDV0fd2_C9kLP6k69G36HMg=.214a2c22-d4c5-4714-a992-492d54b761ef@github.com>
 <swy_Y1FL5xUf2t9ftkQ3qvUa1g5bWwPJr28Jy5VTbnY=.c7810add-450d-4a44-8de5-6ded98123d59@github.com>
 <C9yiRaMrn2xaUyKYG99jEoCnBKKukxcX44JqpVgRQZM=.65b47bf9-1821-4f0b-9083-c6e9669d1732@github.com>
Message-ID: <SxIsYDo9yhsXAX14hGJmsrsFKOVQd_GAt6Tr-SG6UJ0=.81d38b05-541a-4cb8-a70f-3e42f8dd6b6f@github.com>

On Tue, 30 Apr 2024 05:54:03 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> How hard is it to create a new test for this issue?

The issue was discovered by failing a closed test that you wrote some time ago.

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

PR Comment: https://git.openjdk.org/jdk/pull/18950#issuecomment-2084631823

From tr at openjdk.org  Tue Apr 30 08:01:06 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 30 Apr 2024 08:01:06 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
References: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
Message-ID: <SuCE5O7P5NW7K0zmI4H-8mgEuSvlbg_u8egbRTXSN18=.4da00874-5753-48cb-b972-740c80e7a31b@github.com>

On Fri, 26 Apr 2024 21:37:56 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updating giflib, clientlibs tests are green on all platforms

I did reviewed the changes against the updated library, everything is Good. However the copywrite of _COPYING_ file [here](https://github.com/openjdk/jdk/blob/8d0c538b860abca6dd9047a506234933ea90b32b/src/java.desktop/share/native/libsplashscreen/giflib/COPYING#L1) is not updated, is it on purpose ?

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

PR Review: https://git.openjdk.org/jdk/pull/18985#pullrequestreview-2030503079

From psadhukhan at openjdk.org  Tue Apr 30 10:29:07 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 30 Apr 2024 10:29:07 GMT
Subject: RFR: 8226990: GTK & Nimbus LAF: Tabbed pane's background color is
 not expected one when change the opaque checkbox. [v10]
In-Reply-To: <3cuOLs-Q6ycJrKrRey_ww2YQQemNvaUOx2kwcLmsc9U=.02532e64-f3b0-4ffd-b2db-23f436cb32bf@github.com>
References: <ocbuiFOZ_07DpNMmrXMboVca3BELzciMcO3JzrfXIdo=.0a003b8e-86dc-4072-90e7-ed2a9423a086@github.com>
 <3cuOLs-Q6ycJrKrRey_ww2YQQemNvaUOx2kwcLmsc9U=.02532e64-f3b0-4ffd-b2db-23f436cb32bf@github.com>
Message-ID: <7-3xcY82vyT_8K_EdqhpOKzJHt-8Rs0wCwoQZyW-KeE=.169e2031-03df-4381-948b-5fa9ed8d9108@github.com>

On Fri, 19 Apr 2024 05:10:15 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> JTabbedPane's content area, tab area and tab background color are not as expected when opaque is set to true or false. 
>> The proposed fix is to handle the TabbedPane's background color in installed LAFs. Manual test is added to support the fix and there is no regression caused by the fix. 
>> 
>> Proposed fix is tested in Ubuntu 22.04 and Oracle linux.
>> 
>> CI link is posted in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   instruction and copyright year update

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 63:

> 61:             Check the default behaviour of the tabbed pane:
> 62:               - the area behind tabs is transparent (it must be green).
> 63:               - the tabs area is opaque (it must be red, except the selected tab which must be gray).

As per my testing in windows, this is not satisfied for Nimbus and all tabs are gray, not only the selected one..
Is this a bug not solved yet?
Although you specify down below that tabs color are specific to nimbus style, this is prone to misinterpretation and can cause further issue..If it cannot be satisfied for Nimbus, it needs to be specified here upfront...

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 78:

> 76:               - the content area is opaque (it must be gray).
> 77: 
> 78:             Check this behaviour for other LAFs and tab layout.

Since we check for only selected L&Fs like Metal/Nimbus/GTK/Aqua it is probably better to mention  to check behaviour by clicking on present L&F button and tab layout..
Also, since this test is for all platforms, did you test on mac?

test/jdk/javax/swing/JTabbedPane/TestJTabbedPaneOpaqueColor.java line 99:

> 97:               - the tabs are opaque (it must be red, except the selected tab which must be gray).
> 98:             when unchecked:
> 99:               - the tabs are transparent (it must be gree).

gree->green

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1584257458
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1584537667
PR Review Comment: https://git.openjdk.org/jdk/pull/17720#discussion_r1584257656

From tr at openjdk.org  Tue Apr 30 10:57:05 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 30 Apr 2024 10:57:05 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions
In-Reply-To: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
Message-ID: <X6bHcqigD55oGY0zLOLp80rkMsBgxhNymkcI63SP5RI=.a5671555-7e6e-4df6-b297-b43d1f55c226@github.com>

On Mon, 29 Apr 2024 23:24:19 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

One observation is that, after the updates the size of whole test window is slightly increased in height where the second Frame which has options is out of the window frame. When the taskbar is at bottom nothing seems to be visible. 
One option is to limit the instruction rows or to use `PassFailJFrame.splitUI` instead of `PassFailJFrame.splitUIBottom` (Offcourse in splitUI the second Frame occupies the whole screen length which is not required).

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 96:

> 94:         "hide,iconify,show and restore" case.<br><br>
> 95: 
> 96:         If you observe the proper behavior for all the combinations, press PASS else FAIL.<br>

Please limit the column length to 80, here and in some other places too.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19008#pullrequestreview-2030930422
PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1584566397

From tr at openjdk.org  Tue Apr 30 11:03:05 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 30 Apr 2024 11:03:05 GMT
Subject: RFR: 8327696: [TESTBUG]
 "javax/swing/JTable/KeyBoardNavigation/KeyBoardNavigation.java" test
 instruction needs to be corrected [v2]
In-Reply-To: <tcK_IrbV7_Jpf4VIqelNHhhulZP01K2VN7Y8VqLhE8E=.f5d32017-35f5-46cf-a766-b975652adcb8@github.com>
References: <w9z3b2xdowm-OWyhLzm6sQhxD8Xu5XETe0olkrsuIGQ=.5abd0eb2-a073-4ce6-a738-ec296a876267@github.com>
 <Kq8Gv5_G7yMscWPJEQ8XQaDyEq5ppUW8RE47c1QNIgE=.0d2fd125-e544-47bf-a4ee-c03a8f0cd5fb@github.com>
 <tcK_IrbV7_Jpf4VIqelNHhhulZP01K2VN7Y8VqLhE8E=.f5d32017-35f5-46cf-a766-b975652adcb8@github.com>
Message-ID: <nmaOIgUA0RbLjJQGSNfeiLGhZ54LtHJQvtvWK0ncQ4g=.6c55f72d-c1af-4eed-8069-7e09d68abd74@github.com>

On Thu, 25 Apr 2024 10:06:35 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 updates
>
> test/jdk/javax/swing/JTable/KeyBoardNavigation.java line 222:
> 
>> 220:                 Ctrl+\\ - De-select all
>> 221:                 Shift-Up/Down Arrow -  extend selection up/down one row
>> 222:                 Shift-Left/Right Arrow - extend selection left/right one
> 
> No extended selection of columns only focus changed from one cell to another.

In JTable the columnSelection is disabled by default and rowSelection is enabled. Since the whole is selected already in this scenario, extension is not visible. To verify this one you might have to enable Column Selection also.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18855#discussion_r1584585250

From tr at openjdk.org  Tue Apr 30 11:36:05 2024
From: tr at openjdk.org (Tejesh R)
Date: Tue, 30 Apr 2024 11:36:05 GMT
Subject: RFR: 8331142: Add test for number of loader threads in
 BasicDirectoryModel [v2]
In-Reply-To: <B_-OHAIBsbdBoUv4pQoe39sU8WgY94Y9pmHAhPQ0a4E=.5a5d96e9-d964-4c62-ad39-a279c4afd61c@github.com>
References: <rgEIHR1JTsKEvhHAFzPYy4cq9o2BH9fEpcuF5Nz5wvQ=.edbb1100-78c7-48cc-a7d7-941f1ae1bb0b@github.com>
 <B_-OHAIBsbdBoUv4pQoe39sU8WgY94Y9pmHAhPQ0a4E=.5a5d96e9-d964-4c62-ad39-a279c4afd61c@github.com>
Message-ID: <gw-3gB_WOiEIkrv04bT2TKVe0gOTCg8Vm6I2wz5Xg98=.c36d6ae2-b3f0-4a2b-ae7e-97b6247562ef@github.com>

On Mon, 29 Apr 2024 19:59:18 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> This PR provides a regression test for [JDK-8325179](https://bugs.openjdk.org/browse/JDK-8325179): _Race in BasicDirectoryModel.validateFileCache_ reviewed in #18111.
>> 
>> The test is inspired and based on `ConcurrentModification` that I wrote for [JDK-8327137](https://bugs.openjdk.org/browse/JDK-8327137) / [JDK-8323670](https://bugs.openjdk.org/browse/JDK-8323670).
>> 
>> **How the test works**
>> 
>> The test creates a temporary directory in the current directory and creates a number of files in it. (The number of files is controlled by `NUMBER_OF_THREADS` constant). Then the test creates `JFileChooser` in the temporary directory.
>> 
>> The test starts several scanner threads, the number is controlled by `NUMBER_OF_THREADS`, which repeatedly call `fileChooser.rescanCurrentDirectory()`. This results in calling `BasicDirectoryModel.validateFileCache` which starts a background thread ? "Basic L&F File Loading Thread" ? to enumerate the files.
>> 
>> The test runner thread and scanner threads are synchronised with `CyclicBarrier`, this ensures all the scanner threads start at the same time. After a short delay, the runner thread takes a snapshot of live threads. After a longer delay, the operation is repeated. See the `getThreadSnapshot` method. (The number of snapshots is controlled by `SNAPSHOTS` constant.)
>> 
>> The number of File Loading Threads in each snapshot is counted. There should be no more than two threads. It is possible that thread two such threads after JDK-8325179 is fixed: the existing thread is interrupted but hasn't exited yet, and a new thread is already created.
>> 
>> The test fails consistently without the fix for JDK-8325179. On Windows, the output looks like this:
>> 
>> 
>> Number of snapshots: 20
>> Number of snapshots where number of loader threads:
>>   = 1: 0
>>   = 2: 0
>>   > 2: 20
>> java.lang.RuntimeException: Detected 20 snapshots with several loading threads
>>         at LoaderThreadCount.runTest(LoaderThreadCount.java:132)
>>         at LoaderThreadCount.wrapper(LoaderThreadCount.java:72)
>>         at java.base/java.lang.Thread.run(Thread.java:1583)
>> 
>> 
>> On Linux and macOS, there's more variation, for example I got the following output on one of Linux systems:
>> 
>> 
>> Number of snapshots: 15
>> Number of snapshots where number of loader threads:
>>   = 1: 7
>>   = 2: 2
>>   > 2: 6
>> 
>> 
>> The test passes on the builds where JDK-8325179 is present.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suppress throwing exceptions while deleting files

Looks Good to me.

Marked as reviewed by tr (Committer).

-------------

Marked as reviewed by tr (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18957#pullrequestreview-2031028809
PR Review: https://git.openjdk.org/jdk/pull/18957#pullrequestreview-2031029437

From magnus.ihse.bursie at oracle.com  Tue Apr 30 12:16:14 2024
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 30 Apr 2024 14:16:14 +0200
Subject: Usage of iconv()
In-Reply-To: <91874482-df68-4e76-99e9-4fb90ef2c7a7@oracle.com>
References: <20240423121114.EE241662C87@dd33810.kasserver.com>
 <e9f7107a-4f9c-4511-9270-9bb08f7bca87@oracle.com>
 <91874482-df68-4e76-99e9-4fb90ef2c7a7@oracle.com>
Message-ID: <77bc954e-e0bb-40f3-a602-cb58cb7f74a3@oracle.com>

On 2024-04-25 20:30, Philip Race wrote:

>
>
> On 4/24/24 4:24 AM, Magnus Ihse Bursie wrote:
>> That is a good question. libiconv is used only on macOS and AIX, for 
>> a few libraries, as you say. I just tried removing -liconv from the 
>> macOS dependencies and recompiled, just to see what would happen. 
>> There were three instances for macOS: libsplashscreen, libjdwp and 
>> libinstrument.
>>
>>
>>
>> libsplashscreen uses it in splashscreen_sys.m, where it is used to 
>> convert the jar file name.
>
> This is called from the launcher, in java.base/share/native/libjli/java.c
>
>
>>
>> libjdwp uses it in utf_util.c, where it is used to convert file name 
>> and command lines, iiuc.
>>
>> It is likely that we have similar (but better) ways to convert 
>> charsets elsewhere in our libraries that can be used instead of 
>> libiconv. I guess these are not the only two places where a filename 
>> must be converted from the platform charset to UTF8.
>
> So whatever replacement there might be, it needs to be something that 
> is available very early in the life of the VM, in fact before there is 
> a VM running.

Agreed. But it seems to be that this is something that needs to be 
handled by libjli, to properly deal with paths and command lines. I'm 
wondering if the places which to *not* use iconv (or similar) is 
actually incorrect.

/Magnus

>
> -phil.

From duke at openjdk.org  Tue Apr 30 15:04:20 2024
From: duke at openjdk.org (cyberfoxmeow)
Date: Tue, 30 Apr 2024 15:04:20 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: <l8JzvLhfE7NkxXzFxbKX55B_HvlaCl2Oo4pN-ag6lLo=.45d88ae6-473f-45be-b5ae-da2df5b4e4bb@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

???????

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13055#issuecomment-2084111526

From azvegint at openjdk.org  Tue Apr 30 16:53:06 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 30 Apr 2024 16:53:06 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures [v2]
In-Reply-To: <bX30-_5tlMtvAFXkOmzXyguGcfBkSwm86lz_rGlNRxA=.1944ec74-bf02-4ebf-ba88-e3680e9f1ef9@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
 <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>
 <bX30-_5tlMtvAFXkOmzXyguGcfBkSwm86lz_rGlNRxA=.1944ec74-bf02-4ebf-ba88-e3680e9f1ef9@github.com>
Message-ID: <oNHSglIcYKjeSRwaRB-wyHbNw5W0hIoaK4NEGxp5NrY=.d571ef4a-6370-445a-a7f4-5ecdc4cd931c@github.com>

On Tue, 30 Apr 2024 05:47:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> test/jdk/java/awt/Focus/6981400/Test1.java line 186:
> 
>> 184:         Util.clickOnComp(compToClick, robot);
>> 185: 
>> 186:         if (Platform.isOnWayland()) {
> 
> If the goal is just to move the window to the front then can we try "toFront + click on title" on X11 and just "toFront" on Wayland?

Do we really need an additional click on the title in this case?
Just `toFront` should be enough on all platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18995#discussion_r1585196890

From honkar at openjdk.org  Tue Apr 30 17:18:21 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 17:18:21 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v2]
In-Reply-To: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
Message-ID: <x2AF87Loos1mjolfQqhnRG4fXEeal0DESeBZBJBau54=.29535d5b-7aef-4b35-8c2b-b34111466346@github.com>

> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  review changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19008/files
  - new: https://git.openjdk.org/jdk/pull/19008/files/cc96358b..b191cc66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=00-01

  Stats: 33 lines in 1 file changed: 3 ins; 3 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/19008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19008/head:pull/19008

PR: https://git.openjdk.org/jdk/pull/19008

From honkar at openjdk.org  Tue Apr 30 17:22:05 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 17:22:05 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v2]
In-Reply-To: <X6bHcqigD55oGY0zLOLp80rkMsBgxhNymkcI63SP5RI=.a5671555-7e6e-4df6-b297-b43d1f55c226@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
 <X6bHcqigD55oGY0zLOLp80rkMsBgxhNymkcI63SP5RI=.a5671555-7e6e-4df6-b297-b43d1f55c226@github.com>
Message-ID: <oBy6zAFYNYjWmZOjZgrpxyVsX03MngNt3K7YW05EFaI=.5884a541-453c-4be2-a90b-ec49de55d9af@github.com>

On Tue, 30 Apr 2024 10:54:36 GMT, Tejesh R <tr at openjdk.org> wrote:

> One observation is that, after the updates the size of whole test window is slightly increased in height where the second Frame which has options is out of the window frame. When the taskbar is at bottom nothing seems to be visible.
> One option is to limit the instruction rows or to use `PassFailJFrame.splitUI` instead of `PassFailJFrame.splitUIBottom` (Offcourse in splitUI the second Frame occupies the whole screen length which is not required).

PassFailJFrame.splitUI is not a good option as it causes a lot of empty space in this case. I have reduced the log area instead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19008#issuecomment-2086082905

From honkar at openjdk.org  Tue Apr 30 17:26:17 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 17:26:17 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v3]
In-Reply-To: <Br5PF0pWBfV_9LtdRTn4kj4s9eIEqid57msiJp3ZtDQ=.530240c0-50f4-4308-9a9b-8408e98eaa57@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
 <Br5PF0pWBfV_9LtdRTn4kj4s9eIEqid57msiJp3ZtDQ=.530240c0-50f4-4308-9a9b-8408e98eaa57@github.com>
Message-ID: <7PKPJxE_gyzxeiNRakkfjd5AXGPvunSIiyPjcWulPyI=.cbfa2e73-2128-43eb-b08d-14133c818b94@github.com>

On Tue, 30 Apr 2024 04:28:22 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test frame size
>
> test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 122:
> 
>> 120:         PassFailJFrame
>> 121:                 .builder()
>> 122:                 .title("GetBoundsResizeTest Instructions")
> 
> Looks like title is mismatched with the test. Should it be "Frame State and Size Test Instructions" ?

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1585234348

From honkar at openjdk.org  Tue Apr 30 17:26:16 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 17:26:16 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v3]
In-Reply-To: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
Message-ID: <mFMt6FwQmBURS67HukAnaJgjEEFf-RvR87dclXWXKgw=.b9605d33-3514-4351-a954-ea93e902eec0@github.com>

> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  test frame size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19008/files
  - new: https://git.openjdk.org/jdk/pull/19008/files/b191cc66..bc06131e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19008/head:pull/19008

PR: https://git.openjdk.org/jdk/pull/19008

From honkar at openjdk.org  Tue Apr 30 17:36:19 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 17:36:19 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v4]
In-Reply-To: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
Message-ID: <I9RQXxLm4qHLovp_GCjFji1dZTXw0nb_LX5jH-YjYaw=.62f1e375-f738-4416-a75c-ed981847dcd9@github.com>

> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  removed redudant test summary

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19008/files
  - new: https://git.openjdk.org/jdk/pull/19008/files/bc06131e..7a4bacd2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=02-03

  Stats: 12 lines in 1 file changed: 0 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/19008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19008/head:pull/19008

PR: https://git.openjdk.org/jdk/pull/19008

From abhiscxk at openjdk.org  Tue Apr 30 17:52:06 2024
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 30 Apr 2024 17:52:06 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v4]
In-Reply-To: <I9RQXxLm4qHLovp_GCjFji1dZTXw0nb_LX5jH-YjYaw=.62f1e375-f738-4416-a75c-ed981847dcd9@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
 <I9RQXxLm4qHLovp_GCjFji1dZTXw0nb_LX5jH-YjYaw=.62f1e375-f738-4416-a75c-ed981847dcd9@github.com>
Message-ID: <oeA5ms72fjF9AlcD83_tTHPajiXfqiSdSzhLpptkpX4=.9dabe0dd-c7fd-4e4f-b3cd-5aa8b646fcc5@github.com>

On Tue, 30 Apr 2024 17:36:19 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed redudant test summary

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 114:

> 112:         PassFailJFrame
> 113:                 .builder()
> 114:                 .title("Frame Stateand Size Test Instructions")

Suggestion:

                .title("Frame State and Size Test Instructions")

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1585264696

From honkar at openjdk.org  Tue Apr 30 17:57:14 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 17:57:14 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v5]
In-Reply-To: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
Message-ID: <coTIs_5jlgfGLNzWD06sJAHX9Ol0nFLkob59okizLMk=.dbf9c6de-c187-450f-9989-335460121c22@github.com>

> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor spacing

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19008/files
  - new: https://git.openjdk.org/jdk/pull/19008/files/7a4bacd2..fad2ff39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19008/head:pull/19008

PR: https://git.openjdk.org/jdk/pull/19008

From honkar at openjdk.org  Tue Apr 30 18:26:12 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 18:26:12 GMT
Subject: RFR: 8280988: [XWayland] Click on title to request focus test
 failures [v2]
In-Reply-To: <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>
References: <ITgmcFn3ArpGLIzRMqS0yx2AXkt78sonW04_GrCTvbw=.79d3256c-2b8b-416c-8fb8-382c1cdaaf92@github.com>
 <XMPlkcYXyaFZeP_Z7g6NKo68uB0P1pcg3ETfQEe8w9Y=.7f220759-0b17-4134-bd94-821c6e9e7363@github.com>
Message-ID: <X4EHZ2k_w8ufPciTLb3ZbGsiT_Fg_xjjEWwPn51mrsY=.591f8e89-8b46-418c-81dd-b91d37c0ca16@github.com>

On Tue, 30 Apr 2024 02:02:30 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Some tests try to get the focus of a window by clicking on its title bar.
>> 
>> On XWayland, however, emulating mouse clicks with XTEST currently only affects the XWayland server, not the window decorations, so trying to click on the window title will have no effect.
>> 
>> So the solution is to click inside the window or call `toFront()` to get the window focused.
>> 
>> Some tests have issues with AWT/Swing calls not being on EDT, it is not the goal of this change to fix them as they require way too many code changes, and make this PR hard to review.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Updated changes look good.

-------------

Marked as reviewed by honkar (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18995#pullrequestreview-2032183794

From dnguyen at openjdk.org  Tue Apr 30 18:34:52 2024
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 30 Apr 2024 18:34:52 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
References: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
Message-ID: <gPZxcjr7ptk1UQil0LYHi9X2ioK5T39WQm___BdetJc=.bcf61636-951e-4e6e-9b66-c8201c3dd5ee@github.com>

On Fri, 26 Apr 2024 21:37:56 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Updating giflib, clientlibs tests are green on all platforms

Changes look good. Address the not needed comments mentioned in the other review.

-------------

PR Review: https://git.openjdk.org/jdk/pull/18985#pullrequestreview-2032197574

From achung at openjdk.org  Tue Apr 30 18:49:55 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 30 Apr 2024 18:49:55 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <SuCE5O7P5NW7K0zmI4H-8mgEuSvlbg_u8egbRTXSN18=.4da00874-5753-48cb-b972-740c80e7a31b@github.com>
References: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
 <SuCE5O7P5NW7K0zmI4H-8mgEuSvlbg_u8egbRTXSN18=.4da00874-5753-48cb-b972-740c80e7a31b@github.com>
Message-ID: <eeBUQXg3HlRwBgGMcMVV1gbZLV458VFjfRgiTMHzQNU=.91ffc158-a0ae-4e7e-b51c-8458ca08df4a@github.com>

On Tue, 30 Apr 2024 07:58:25 GMT, Tejesh R <tr at openjdk.org> wrote:

> here

There are no changes to the COPYING file in the newest version of giblib so there weren't any changes here either

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18985#issuecomment-2086543204

From achung at openjdk.org  Tue Apr 30 18:49:56 2024
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 30 Apr 2024 18:49:56 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <ShC4W1cAwrda_a5g_4xErxsnM93Q9v-MRx9aZRw4D7s=.99209477-4e6e-4b10-87be-885b5fa0dae9@github.com>
References: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
 <T2xdTHoXHvkRf8L7XH4yPPOYu7aAbkFK0E0hXzcBP-o=.3b9844c7-c2ac-4581-b8ec-e045d59fa59e@github.com>
 <ShC4W1cAwrda_a5g_4xErxsnM93Q9v-MRx9aZRw4D7s=.99209477-4e6e-4b10-87be-885b5fa0dae9@github.com>
Message-ID: <CytGU-X2K05f7rDz67jI4VVJO4bgx0J_ftsiKtW69To=.9e46087f-157e-4927-b1f5-8a26c8dc9b23@github.com>

On Mon, 29 Apr 2024 21:05:34 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> src/java.desktop/share/native/libsplashscreen/giflib/gif_hash.h line 40:
>> 
>>> 38: #include <unistd.h>
>>> 39: #endif
>>> 40: /** End JDK modifications to support building on Windows **/
>> 
>> Do we still need this ?
>
> The GIFLIB version 5.2.2 adds the `ifndef` wrap, and it is no longer the "JDK modification", so it looks like our comment can be removed

does this also apply for the other JDK modification for old compilers as well?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18985#discussion_r1585334886

From duke at openjdk.org  Tue Apr 30 19:32:54 2024
From: duke at openjdk.org (lawrence.andrews)
Date: Tue, 30 Apr 2024 19:32:54 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v5]
In-Reply-To: <coTIs_5jlgfGLNzWD06sJAHX9Ol0nFLkob59okizLMk=.dbf9c6de-c187-450f-9989-335460121c22@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
 <coTIs_5jlgfGLNzWD06sJAHX9Ol0nFLkob59okizLMk=.dbf9c6de-c187-450f-9989-335460121c22@github.com>
Message-ID: <a7bCOBgO9Ne6SC5uQ3NVL0dZFlnA49wtdrmMy6kCiOk=.05e8a208-63f1-4dd7-9636-6ac1e91ab7d2@github.com>

On Tue, 30 Apr 2024 17:57:14 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor spacing

test/jdk/java/awt/Frame/FrameStateTest/FrameStateTest.java line 177:

> 175:             add(b3 = new Button("Iconify"));
> 176:             add(b4 = new Button("Iconify and Restore"));
> 177:             add(b5 = new Button("Hide and show"));

To be consistent with other buttons , this button can be changed from  text "Hide and show"   to "Hide and show"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19008#discussion_r1585429023

From honkar at openjdk.org  Tue Apr 30 20:38:06 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 30 Apr 2024 20:38:06 GMT
Subject: RFR: JDK-8329692 : Add more details to FrameStateTest.java test
 instructions [v6]
In-Reply-To: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
References: <v1JEZ4deU-4XXrYXCdfumFTyugbT6h0_JOtR_CGl9WA=.f8eb40b4-cbde-4c52-b1d5-bd7bf88a140f@github.com>
Message-ID: <ZPa2jTpqW_qpkA6AYG1j59vA4MTPs4J4_KFAo5FUQOs=.d25828e0-d20d-4fe2-8bb2-2b04eb1ff257@github.com>

> For the following manual test, more instructions are added as to what to expect for "hide,iconify and show" vs "hide,iconify,show and restore" for clarity.

Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:

  minor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19008/files
  - new: https://git.openjdk.org/jdk/pull/19008/files/fad2ff39..88f5d048

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19008&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/19008.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19008/head:pull/19008

PR: https://git.openjdk.org/jdk/pull/19008

From azvegint at openjdk.org  Tue Apr 30 21:35:55 2024
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 30 Apr 2024 21:35:55 GMT
Subject: RFR: 8328999: Update GIFlib to 5.2.2
In-Reply-To: <CytGU-X2K05f7rDz67jI4VVJO4bgx0J_ftsiKtW69To=.9e46087f-157e-4927-b1f5-8a26c8dc9b23@github.com>
References: <ZYuZniqjXXorktXGssbZ2OyOj9UaxZcqoEtl3yFtQCY=.1d4166ff-d185-46a0-bf44-ebd21e36d975@github.com>
 <T2xdTHoXHvkRf8L7XH4yPPOYu7aAbkFK0E0hXzcBP-o=.3b9844c7-c2ac-4581-b8ec-e045d59fa59e@github.com>
 <ShC4W1cAwrda_a5g_4xErxsnM93Q9v-MRx9aZRw4D7s=.99209477-4e6e-4b10-87be-885b5fa0dae9@github.com>
 <CytGU-X2K05f7rDz67jI4VVJO4bgx0J_ftsiKtW69To=.9e46087f-157e-4927-b1f5-8a26c8dc9b23@github.com>
Message-ID: <GPHPACRhVXJyJNZfDq1dGKklarrvVSxejnmcEGCv34s=.5d2f9afc-c88f-4d3f-b1a6-406855dff5be@github.com>

On Tue, 30 Apr 2024 18:46:51 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> The GIFLIB version 5.2.2 adds the `ifndef` wrap, and it is no longer the "JDK modification", so it looks like our comment can be removed
>
> does this also apply for the other JDK modification for old compilers as well?

Regarding the `JDK modifications to support building using old compilers` from `gif_lib.h`:

I found my old [review request](https://mail.openjdk.org/pipermail/awt-dev/2015-April/009269.html), that mentioned [why](https://stackoverflow.com/questions/8548521/trying-to-use-include-stdbool-h-in-vs-2010/8549206) these changes were added (because of the issue with VS 2010).

However, this issue [should be fixed as of VS 2013](
https://devblogs.microsoft.com/cppblog/c99-library-support-in-visual-studio-2013/).

So you should probably check the build without these changes, and if it works fine, remove them.

The only concern is if some of the JDKs we are going to backport this upgrade use VS below 2013 (I am not sure if we have any), but I think we can bring our fix back to the specific backport.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/18985#discussion_r1585548477