From tr at openjdk.org  Fri Dec  1 06:31:10 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 1 Dec 2023 06:31:10 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v11]
In-Reply-To: <3c-r5WZdBvId2JwggeBMWEuO5Ac1FCsMm2614_mdcPI=.cc31ff34-75eb-4e69-a7d8-d20009e0e18a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <YYEKuel6LVZui2vhUVxNw8SWCUQIV4YvwP99ZzI9rLQ=.139ab07e-9d58-4d66-aeb6-e88e58356705@github.com>
 <8Mqh5Fc1StgVQ0UMyQfJVHMwhrFvCAxmwmQq8hMWVuE=.d64f8c8f-c8f4-4fe7-bfcb-44f837c48e6a@github.com>
 <7gEx6NNJchYlCUiN1b2n_Vf_MyNf_REtW--NOiOoCQ4=.46444e22-e6e2-4b70-acf5-cda54388b66d@github.com>
 <erik8G-cOH9jtt6ODfV1kMvHrE2nQrdjsFr1L-xb1G8=.7bd0c1f3-4b2c-49dc-b4eb-0debefc255b2@github.com>
 <3c-r5WZdBvId2JwggeBMWEuO5Ac1FCsMm2614_mdcPI=.cc31ff34-75eb-4e69-a7d8-d20009e0e18a@github.com>
Message-ID: <Nspo-FUqSzKfowVHm3mMA3Kuyi_p0t94_QgY8GuvQis=.09f99f75-d007-481f-b853-6e87b8647557@github.com>

On Thu, 30 Nov 2023 17:44:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> You don't call `parent.getWidth()` here, you always call `this.getWidth()`.
>> 
>> I don't know why `JTableHeader` has special handling for it? Yet in the case of `JTableHeader` it may be reasonable: the header follows the table width if it's auto-resizable. I presume the table handles this mode somehow.
>> 
>>> I thought it might be for future purpose, but not sure... Should we retain or just use `parent.getWidth` directly?
>> 
>> In both cases, you call the same implementation of `getWidth`. I'm for removing the `getWidthInRightToLeft` method altogether unless there's a specific purpose for doing it, which I can't see ? use `getWidth` directly.
>
> Did you test RTL with auto-resizing table?

Yeah, in that case the table will fully occupied JPanel.

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

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

From psadhukhan at openjdk.org  Fri Dec  1 06:37:12 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Fri, 1 Dec 2023 06:37:12 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
Message-ID: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>

CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

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

Commit messages:
 - 8319925: CSS.BackgroundImage incorrectly uses double-checked locking

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

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

From duke at openjdk.org  Fri Dec  1 09:21:05 2023
From: duke at openjdk.org (songpv-imt)
Date: Fri, 1 Dec 2023 09:21:05 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v6]
In-Reply-To: <zt22hWY8tUxfEtKD_bcXr5J2a4YByxfks6iQi9p6dFY=.3be511e7-e243-4945-a7b3-bce078e55b3d@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <FyVlQDMdF7tji0yw8dEUI9VMRaqayYv0qhvmth_VywQ=.09f4d384-5deb-4c73-82df-7288707d28d2@github.com>
 <8pVL-HXwf1kF_TQ3NxX5O0qwoxW9OahYK9sXwMGYZqc=.b1cb415c-500d-4939-b94d-2808a7847649@github.com>
 <zt22hWY8tUxfEtKD_bcXr5J2a4YByxfks6iQi9p6dFY=.3be511e7-e243-4945-a7b3-bce078e55b3d@github.com>
Message-ID: <VendvygOuddaRJpFpqrnw89y9bc8LKcpRr3t1MvMozs=.65a75cd0-ec08-45c3-9005-af9b6e714d3c@github.com>

On Tue, 28 Nov 2023 19:32:56 GMT, Alexandre Iline <shurailine at openjdk.org> wrote:

>> Hmm... Are you suggesting instead of using SYNC_LOCK, for better code transparency, we should place the code that accesses the listener's fields from the main thread into AWT Event Queue with EventQueue.invokeAndWait? Can you please check if the update code meets your suggestion? Thanks.
>
>> Hmm... Are you suggesting instead of using SYNC_LOCK, for better code transparency, we should place the code that accesses the listener's fields from the main thread into AWT Event Queue with EventQueue.invokeAndWait? Can you please check if the update code meets your suggestion? Thanks.
> 
> Yes. Half of the access to the state of the listener is already on the even queue. It would be pretty transparent to make the other part of the access to go through the queue.

@shurymury The last code commit has implemented the changes based on your suggestion. Can you please advise what other step I should take to complete this bug ? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1835745445

From tr at openjdk.org  Fri Dec  1 09:26:41 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 1 Dec 2023 09:26:41 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v13]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>

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

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/9fab11f8..0b8ad711

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

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

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

From duke at openjdk.org  Fri Dec  1 09:37:07 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Fri, 1 Dec 2023 09:37:07 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>
Message-ID: <VeZslpXLMOc2EDvSFl2wmOb_VdHHN7A5Gp6F7MK9B5g=.becc5889-a79e-4ae1-af05-11bf85433b07@github.com>

On Thu, 30 Nov 2023 21:41:53 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.
>
> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 930:
> 
>> 928:             fp_pw_thread_loop_unlock(pw.loop);
>> 929:             releaseToken(env, jtoken, token);
>> 930:             return RESULT_ERROR;
> 
> I think that the fix can be improved a bit.
> Right now it just gives a black image on failure. We can try to add another attempt to get the image we need.

@azvegint Thanks for reviewing this Alexander! I dont think re-trying here is gonna work at all. The libpipewire docs leave a lot to be desired so I was using their code as reference for this patch and according to their current implementation if it gets to a state of core error or if it transitions to PW_STREAM_STATE_ERROR or PW_STREAM_STATE_UNCONNECTED from any other state that means a fatal (unrecoverable) error meaning you have to bail and start from scratch eg re-init, get new stream etc ie there is no transition from such state to a normal state where you could make a re-try.

The problem with blank screen in this case stems from the API design here. Currently, when an error here the higher level API, as far as I can tell, only covers the permissions case by throwing security exception but completely ignores any other possible errors instead of propagating them to the caller, either as exception or return value, and so the caller gets an empty/black image on failure but is simply not aware of any encountered error/s and thus could incorrectly assume the data is legit.

What should be done to address that is to propagate those errors all the way back to the API caller but doing so would require changing related API method signatures or introducing new throws that the callers would need to catch. I dunno about the stability levels and contracts on those API  involved but if they are mendable I can look into changing them tho I think it is better to do it as separate patch. Tell me what you think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1411840126

From mkartashev at openjdk.org  Fri Dec  1 11:25:06 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 1 Dec 2023 11:25:06 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
Message-ID: <6rYHuUwz5xeCDf2KyyxWE-Bzom1j-pvKoe_d2B4isl8=.0d733f72-8bb3-4a8f-ac3d-8872306cd27a@github.com>

On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 46:

> 44:                                    }
> 45: 
> 46: static volatile gboolean hasPipewireFailed = FALSE;

I wonder why does `hasPipewireFailed` have to be `volatile`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1411960033

From aivanov at openjdk.org  Fri Dec  1 13:01:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Dec 2023 13:01:46 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v13]
In-Reply-To: <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>
Message-ID: <AmhYOaVV2rCiWcXnA8jHfpplEakDslhvqzpVNsm8fEE=.9d7fceb1-6c57-4908-8e6f-edb438662057@github.com>

On Fri, 1 Dec 2023 09:26:41 GMT, Tejesh R <tr at openjdk.org> wrote:

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

Looks good now.

src/java.desktop/share/classes/javax/swing/JTable.java line 9804:

> 9802: 
> 9803:     }  // inner class AccessibleJTable
> 9804: 

You should preserve this blank line.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16374#pullrequestreview-1759761739
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1412073682

From duke at openjdk.org  Fri Dec  1 13:12:09 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Fri, 1 Dec 2023 13:12:09 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <6rYHuUwz5xeCDf2KyyxWE-Bzom1j-pvKoe_d2B4isl8=.0d733f72-8bb3-4a8f-ac3d-8872306cd27a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <6rYHuUwz5xeCDf2KyyxWE-Bzom1j-pvKoe_d2B4isl8=.0d733f72-8bb3-4a8f-ac3d-8872306cd27a@github.com>
Message-ID: <_dy9P1MxDdf1HYmpeaBMMsGU-z14xQ48AisWuQWyKN0=.9176cd29-11dd-4268-8ab5-b9501f050e46@github.com>

On Fri, 1 Dec 2023 11:21:59 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.
>
> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 46:
> 
>> 44:                                    }
>> 45: 
>> 46: static volatile gboolean hasPipewireFailed = FALSE;
> 
> I wonder why does `hasPipewireFailed` have to be `volatile`?

@mkartashev hey, a fellow Sun comrade! (i still have my Sun badge too) :)

This is for similar reasons to the existing 'sessionClosed' being volatile ie bc multiple threads can read/write it and in this particular case a limited scope optimizatiion compiler might decide to otherwise optimize away the 'if' block in this loop
 
https://github.com/openjdk/jdk/pull/16794/commits/6805f72d4b7f33d5bfa0ae5742122d377345c6e2#diff-3ba5df79cdd3da36b21bf29b4e8de462dd61e6a21dfe0816e4d84c18bbfb76b2R927

In practice tho I dont think modern compilers would do that but since there is no real cost of using volatile in this case as there is nothing practical to gain by optimizing around it, its best to explicitly tell the compiler to not mess with it at all than to rely on any assumption that it just would not as those optimizations are implementation dependent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412085551

From mkartashev at openjdk.org  Fri Dec  1 13:47:08 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 1 Dec 2023 13:47:08 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <_dy9P1MxDdf1HYmpeaBMMsGU-z14xQ48AisWuQWyKN0=.9176cd29-11dd-4268-8ab5-b9501f050e46@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <6rYHuUwz5xeCDf2KyyxWE-Bzom1j-pvKoe_d2B4isl8=.0d733f72-8bb3-4a8f-ac3d-8872306cd27a@github.com>
 <_dy9P1MxDdf1HYmpeaBMMsGU-z14xQ48AisWuQWyKN0=.9176cd29-11dd-4268-8ab5-b9501f050e46@github.com>
Message-ID: <HlKLg3pICKdAIXRaz_ChfOuZySxRCYWZ_ld1ne7CDCc=.92a70274-c864-44a7-b94c-d43b6b565d06@github.com>

On Fri, 1 Dec 2023 13:09:52 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> hey, a fellow Sun comrade! (i still have my Sun badge too) :)

:handshake: 

> I dont think modern compilers would do that

I would argue that no standard-compliant compiler would do that.

 `volatile` is very hard to summarize without loosing accuracy (see WG21 6.7.3/7 and Annex C) , but they are about hardware interrupts/signal handlers and the like that can "suddenly" change the value ("modified in ways unknown to the implementation"), not about multithreading and certainly neither replace nor enhance synchronization. 

> compiler might decide to otherwise optimize away the 'if' block in this loop

That would be a (huge) bug in the compiler. The variable is global, the rules of the abstract machine allow for the value to change outside of the loop and outside of the containing function.

FWIW, `sessionClosed` also doesn't have to be volatile.

> there is no real cost of using volatile in this case

I agree that this is hardly the hottest spot of the entire affair of taking a screenshot, but the cost is in readability. `volatile` has a very special meaning and here it is used for a purpose that does not match this meaning. This is at least confusing. Just like you wouldn't use _Atomic in a single-threaded application even though it might cost nothing overall, you shouldn't use volatile simply because it's cost-less in terms of performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412120620

From azvegint at openjdk.org  Fri Dec  1 14:04:08 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Dec 2023 14:04:08 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
Message-ID: <tDWhxkqREtCNgrmG0e8zC842sz0LWTo1_OLHRA6DaIA=.9f79355a-35d6-458c-b992-49ec3f4abf77@github.com>

On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 928:

> 926:         fp_pw_thread_loop_wait(pw.loop);
> 927:         if (hasPipewireFailed) {
> 928:             fp_pw_thread_loop_unlock(pw.loop);

The session may not be closed [immediately](https://github.com/openjdk/jdk/blob/master/src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java#L62), so it could be reused later by a subsequent call.

So I suggest making it explicit:

Suggestion:

            fp_pw_thread_loop_unlock(pw.loop);
            doCleanup();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412117392

From azvegint at openjdk.org  Fri Dec  1 14:04:09 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Dec 2023 14:04:09 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <VeZslpXLMOc2EDvSFl2wmOb_VdHHN7A5Gp6F7MK9B5g=.becc5889-a79e-4ae1-af05-11bf85433b07@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>
 <VeZslpXLMOc2EDvSFl2wmOb_VdHHN7A5Gp6F7MK9B5g=.becc5889-a79e-4ae1-af05-11bf85433b07@github.com>
Message-ID: <p2bnPmfigaVwocFAEFQyTpp_w9kqm660uDRv-RD_CvI=.b0959b74-4018-4fd6-b5de-db73485ad66d@github.com>

On Fri, 1 Dec 2023 09:34:35 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 930:
>> 
>>> 928:             fp_pw_thread_loop_unlock(pw.loop);
>>> 929:             releaseToken(env, jtoken, token);
>>> 930:             return RESULT_ERROR;
>> 
>> I think that the fix can be improved a bit.
>> Right now it just gives a black image on failure. We can try to add another attempt to get the image we need.
>
> @azvegint Thanks for reviewing this Alexander! I dont think re-trying here is gonna work at all. The libpipewire docs leave a lot to be desired so I was using their code as reference for this patch and according to their current implementation if it gets to a state of core error or if it transitions to PW_STREAM_STATE_ERROR or PW_STREAM_STATE_UNCONNECTED from any other state that means a fatal (unrecoverable) error meaning you have to bail and start from scratch eg re-init, get new stream etc ie there is no transition from such state to a normal state where you could make a re-try.
> 
> The problem with blank screen in this case stems from the API design here. Currently, when an error here the higher level API, as far as I can tell, only covers the permissions case by throwing security exception but completely ignores any other possible errors instead of propagating them to the caller, either as exception or return value, and so the caller gets an empty/black image on failure but is simply not aware of any encountered error/s and thus could incorrectly assume the data is legit.
> 
> What should be done to address that is to propagate those errors all the way back to the API caller but doing so would require changing related API method signatures or introducing new throws that the callers would need to catch. I dunno about the stability levels and contracts on those API  involved but if they are mendable I can look into changing them tho I think it is better to do it as separate patch. Tell me what you think.

Sorry for not being clear, I meant by retry to start everything with a new session.
And of course, changing the internal API is not a problem as it is quite small and only used in one place.

Separate patch is fine, I submitted [JDK-8321176](https://bugs.openjdk.org/browse/JDK-8321176) for this, I can do it, but later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412138087

From duke at openjdk.org  Fri Dec  1 14:22:04 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Fri, 1 Dec 2023 14:22:04 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <HlKLg3pICKdAIXRaz_ChfOuZySxRCYWZ_ld1ne7CDCc=.92a70274-c864-44a7-b94c-d43b6b565d06@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <6rYHuUwz5xeCDf2KyyxWE-Bzom1j-pvKoe_d2B4isl8=.0d733f72-8bb3-4a8f-ac3d-8872306cd27a@github.com>
 <_dy9P1MxDdf1HYmpeaBMMsGU-z14xQ48AisWuQWyKN0=.9176cd29-11dd-4268-8ab5-b9501f050e46@github.com>
 <HlKLg3pICKdAIXRaz_ChfOuZySxRCYWZ_ld1ne7CDCc=.92a70274-c864-44a7-b94c-d43b6b565d06@github.com>
Message-ID: <QnMM6e7g_bEoAQGW7GyI-TxmsWwyOlqoYli2q521bh0=.22f1efb0-d7c3-4f7c-9c80-076d62dc2619@github.com>

On Fri, 1 Dec 2023 13:44:21 GMT, Maxim Kartashev <mkartashev at openjdk.org> wrote:

>> @mkartashev hey, a fellow Sun comrade! (i still have my Sun badge too) :)
>> 
>> This is for similar reasons to the existing 'sessionClosed' being volatile ie bc multiple threads can read/write it and in this particular case a limited scope optimizatiion compiler might decide to otherwise optimize away the 'if' block in this loop
>>  
>> https://github.com/openjdk/jdk/pull/16794/commits/6805f72d4b7f33d5bfa0ae5742122d377345c6e2#diff-3ba5df79cdd3da36b21bf29b4e8de462dd61e6a21dfe0816e4d84c18bbfb76b2R927
>> 
>> In practice tho I dont think modern compilers would do that but since there is no real cost of using volatile in this case as there is nothing practical to gain by optimizing around it, its best to explicitly tell the compiler to not mess with it at all than to rely on any assumption that it just would not as those optimizations are implementation dependent.
>
>> hey, a fellow Sun comrade! (i still have my Sun badge too) :)
> 
> :handshake: 
> 
>> I dont think modern compilers would do that
> 
> I would argue that no standard-compliant compiler would do that.
> 
>  `volatile` is very hard to summarize without loosing accuracy (see WG21 6.7.3/7 and Annex C) , but they are about hardware interrupts/signal handlers and the like that can "suddenly" change the value ("modified in ways unknown to the implementation"), not about multithreading and certainly neither replace nor enhance synchronization. 
> 
>> compiler might decide to otherwise optimize away the 'if' block in this loop
> 
> That would be a (huge) bug in the compiler. The variable is global, the rules of the abstract machine allow for the value to change outside of the loop and outside of the containing function.
> 
> FWIW, `sessionClosed` also doesn't have to be volatile.
> 
>> there is no real cost of using volatile in this case
> 
> I agree that this is hardly the hottest spot of the entire affair of taking a screenshot, but the cost is in readability. `volatile` has a very special meaning and here it is used for a purpose that does not match this meaning. This is at least confusing. Just like you wouldn't use _Atomic in a single-threaded application even though it might cost nothing overall, you shouldn't use volatile simply because it's cost-less in terms of performance.

@mkartashev WG21 is C++ standard and this is not. Here is what GNU docs say, specifically, quote "The standards encourage compilers to refrain from optimizations concerning accesses to volatile objects. The C standard leaves it implementation defined as to what constitutes a volatile access.".

Regarding readability I would actually argue the other way. If I see something declared as volatile I would more likely to take care to pay special attention to it which is beneficial for the code in question, especially given those synchronization issues around it. 

Either way, I dont believe there is any practical reason to waste time and have an argument about this, so if you feel strongly about it (I don't) I can drop 'volatile' from both variables if that helps.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412160104

From duke at openjdk.org  Fri Dec  1 14:29:06 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Fri, 1 Dec 2023 14:29:06 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <p2bnPmfigaVwocFAEFQyTpp_w9kqm660uDRv-RD_CvI=.b0959b74-4018-4fd6-b5de-db73485ad66d@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>
 <VeZslpXLMOc2EDvSFl2wmOb_VdHHN7A5Gp6F7MK9B5g=.becc5889-a79e-4ae1-af05-11bf85433b07@github.com>
 <p2bnPmfigaVwocFAEFQyTpp_w9kqm660uDRv-RD_CvI=.b0959b74-4018-4fd6-b5de-db73485ad66d@github.com>
Message-ID: <bFUnj9CoMhWyFVF0m6g-Rbdwtwj9BvXM0UUvUYn5syU=.fbeb15b7-183d-4e75-a1f3-b5208ff20b26@github.com>

On Fri, 1 Dec 2023 14:00:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> @azvegint Thanks for reviewing this Alexander! I dont think re-trying here is gonna work at all. The libpipewire docs leave a lot to be desired so I was using their code as reference for this patch and according to their current implementation if it gets to a state of core error or if it transitions to PW_STREAM_STATE_ERROR or PW_STREAM_STATE_UNCONNECTED from any other state that means a fatal (unrecoverable) error meaning you have to bail and start from scratch eg re-init, get new stream etc ie there is no transition from such state to a normal state where you could make a re-try.
>> 
>> The problem with blank screen in this case stems from the API design here. Currently, when an error here the higher level API, as far as I can tell, only covers the permissions case by throwing security exception but completely ignores any other possible errors instead of propagating them to the caller, either as exception or return value, and so the caller gets an empty/black image on failure but is simply not aware of any encountered error/s and thus could incorrectly assume the data is legit.
>> 
>> What should be done to address that is to propagate those errors all the way back to the API caller but doing so would require changing related API method signatures or introducing new throws that the callers would need to catch. I dunno about the stability levels and contracts on those API  involved but if they are mendable I can look into changing them tho I think it is better to do it as separate patch. Tell me what you think.
>
> Sorry for not being clear, I meant by retry to start everything with a new session.
> And of course, changing the internal API is not a problem as it is quite small and only used in one place.
> 
> Separate patch is fine, I submitted [JDK-8321176](https://bugs.openjdk.org/browse/JDK-8321176) for this, I can do it, but later.

@azvegint do you think it would make sense to do it in the native code or in the upper level Java code ? AND also how many times do you think it would make sense to retry provided this could be a permanent pipewire error and so it wont be sitting there re-trying with the same error forever ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412168434

From mkartashev at openjdk.org  Fri Dec  1 14:32:05 2023
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 1 Dec 2023 14:32:05 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <QnMM6e7g_bEoAQGW7GyI-TxmsWwyOlqoYli2q521bh0=.22f1efb0-d7c3-4f7c-9c80-076d62dc2619@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <6rYHuUwz5xeCDf2KyyxWE-Bzom1j-pvKoe_d2B4isl8=.0d733f72-8bb3-4a8f-ac3d-8872306cd27a@github.com>
 <_dy9P1MxDdf1HYmpeaBMMsGU-z14xQ48AisWuQWyKN0=.9176cd29-11dd-4268-8ab5-b9501f050e46@github.com>
 <HlKLg3pICKdAIXRaz_ChfOuZySxRCYWZ_ld1ne7CDCc=.92a70274-c864-44a7-b94c-d43b6b565d06@github.com>
 <QnMM6e7g_bEoAQGW7GyI-TxmsWwyOlqoYli2q521bh0=.22f1efb0-d7c3-4f7c-9c80-076d62dc2619@github.com>
Message-ID: <o9oG9CGdTplaDtFYjTn5ZbxpDDO3VSt8b3hD3GuRzOM=.8aab14a1-b07e-48e0-97e1-8f042aaaa880@github.com>

On Fri, 1 Dec 2023 14:19:25 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> WG21 is C++ standard and this is not

Oops, I meant WG14, of course.

> if you feel strongly about it (I don't) I can drop 'volatile' from both variables if that helps.

I do. However, formally I am not a reviewer.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412172648

From azvegint at openjdk.org  Fri Dec  1 15:03:07 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Dec 2023 15:03:07 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <bFUnj9CoMhWyFVF0m6g-Rbdwtwj9BvXM0UUvUYn5syU=.fbeb15b7-183d-4e75-a1f3-b5208ff20b26@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>
 <VeZslpXLMOc2EDvSFl2wmOb_VdHHN7A5Gp6F7MK9B5g=.becc5889-a79e-4ae1-af05-11bf85433b07@github.com>
 <p2bnPmfigaVwocFAEFQyTpp_w9kqm660uDRv-RD_CvI=.b0959b74-4018-4fd6-b5de-db73485ad66d@github.com>
 <bFUnj9CoMhWyFVF0m6g-Rbdwtwj9BvXM0UUvUYn5syU=.fbeb15b7-183d-4e75-a1f3-b5208ff20b26@github.com>
Message-ID: <6FLXgPQyuVxwaqG40pSxeIxyCVyYgH75RWsPP353BZc=.c4e18978-acb7-4ce6-ad32-cb9d838327d9@github.com>

On Fri, 1 Dec 2023 14:26:39 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> Sorry for not being clear, I meant by retry to start everything with a new session.
>> And of course, changing the internal API is not a problem as it is quite small and only used in one place.
>> 
>> Separate patch is fine, I submitted [JDK-8321176](https://bugs.openjdk.org/browse/JDK-8321176) for this, I can do it, but later.
>
> @azvegint do you think it would make sense to do it in the native code or in the upper level Java code ? AND also how many times do you think it would make sense to retry provided this could be a permanent pipewire error and so it wont be sitting there re-trying with the same error forever ?  (EDIT): i see you have mentioned in the bug just 1 retry. i think it would still make sense to do something about the case where even the 2nd attempt does not succeed ie notify the caller somehow (retval/exception) that it has failed.

I think it's better to do it in the native, to avoid extra native-java hops.

As for the number of extra attempts, I think one-two is enough.

Something like this (I haven't tested it thoroughly yet):


diff --git a/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c b/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
index 6a7c4124935..a7c5aadb1ae 100644
--- a/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
+++ b/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
@@ -855,6 +855,32 @@ static void arrayToRectangles(JNIEnv *env,
     (*env)->ReleaseIntArrayElements(env, boundsArray, body, 0);
 }
 
+static int makeAnAttempt(
+        const gchar *token,
+        GdkRectangle *requestedArea,
+        GdkRectangle *affectedScreenBounds,
+        gint affectedBoundsLength) {
+    if (!initScreencast(token, affectedScreenBounds, affectedBoundsLength)) {
+        return pw.pwFd;
+    }
+
+    if (!doLoop(*requestedArea)) {
+        return RESULT_ERROR;
+    }
+
+    while (!isAllDataReady()) {
+        fp_pw_thread_loop_lock(pw.loop);
+        fp_pw_thread_loop_wait(pw.loop);
+        if (hasPipewireFailed) {
+            fp_pw_thread_loop_unlock(pw.loop);
+            doCleanup();
+            return RESULT_ERROR;
+        }
+        fp_pw_thread_loop_unlock(pw.loop);
+    }
+    return RESULT_OK;
+}
+
 /*
  * Class:     sun_awt_screencast_ScreencastHelper
  * Method:    closeSession
@@ -911,25 +937,17 @@ JNIEXPORT jint JNICALL Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl
             jx, jy, jwidth, jheight, token
     );
 
-    if (!initScreencast(token, affectedScreenBounds, affectedBoundsLength)) {
-        releaseToken(env, jtoken, token);
-        return pw.pwFd;
-    }
-
-    if (!doLoop(requestedArea)) {
-        releaseToken(env, jtoken, token);
-        return RESULT_ERROR;
-    }
+    int attemptResult = makeAnAttempt(token, &requestedArea,
+                                      affectedScreenBounds, affectedBoundsLength);
 
-    while (!isAllDataReady()) {
-        fp_pw_thread_loop_lock(pw.loop);
-        fp_pw_thread_loop_wait(pw.loop);
-        if (hasPipewireFailed) {
-            fp_pw_thread_loop_unlock(pw.loop);
+    if (attemptResult) {
+        DEBUG_SCREENCAST("First attempt failed with %i, re-trying...\n", attemptResult);
+        attemptResult = makeAnAttempt(token, &requestedArea,
+                                      affectedScreenBounds, affectedBoundsLength);
+        if (attemptResult) {
             releaseToken(env, jtoken, token);
-            return RESULT_ERROR;
+            return attemptResult;
         }
-        fp_pw_thread_loop_unlock(pw.loop);
     }
 
     DEBUG_SCREENCAST("\nall data ready\n", NULL);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412217992

From duke at openjdk.org  Fri Dec  1 15:49:21 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Fri, 1 Dec 2023 15:49:21 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api [v2]
In-Reply-To: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
Message-ID: <p42y34NDKEFEsZFa06DLJqgoXJaN0g1MvneZBMIotxQ=.36b09d9e-8b31-42f2-8eca-7f7b91ebcb43@github.com>

> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

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

 - Merge branch 'openjdk:master' into screencast_robot
 - 8320655: awt screencast robot spin and sync issues with native libpipewire api

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16794/files
  - new: https://git.openjdk.org/jdk/pull/16794/files/6805f72d..e6023b32

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

  Stats: 38277 lines in 1287 files changed: 26232 ins; 6214 del; 5831 mod
  Patch: https://git.openjdk.org/jdk/pull/16794.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16794/head:pull/16794

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

From aivanov at openjdk.org  Fri Dec  1 16:03:06 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Dec 2023 16:03:06 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
Message-ID: <x8tJpiQcv6TU1FUB01BAsdWThAeccyn8nCVM6Pb1tZM=.a94ea672-03a8-4303-b418-54d4fb84b8c0@github.com>

On Fri, 1 Dec 2023 06:31:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16917#pullrequestreview-1760122924

From duke at openjdk.org  Fri Dec  1 16:49:30 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Fri, 1 Dec 2023 16:49:30 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api [v3]
In-Reply-To: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
Message-ID: <H7IWlO1aogmwvubrs79-M9G3EYLcXTpF1EKMmnXZMZg=.1c2a478f-9142-4660-a800-54d0f5dda873@github.com>

> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

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

  8320655: remove volatiles and do explicit cleanup on failure

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16794/files
  - new: https://git.openjdk.org/jdk/pull/16794/files/e6023b32..c764a854

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

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

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

From duke at openjdk.org  Fri Dec  1 16:57:08 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Fri, 1 Dec 2023 16:57:08 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api [v3]
In-Reply-To: <6FLXgPQyuVxwaqG40pSxeIxyCVyYgH75RWsPP353BZc=.c4e18978-acb7-4ce6-ad32-cb9d838327d9@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>
 <VeZslpXLMOc2EDvSFl2wmOb_VdHHN7A5Gp6F7MK9B5g=.becc5889-a79e-4ae1-af05-11bf85433b07@github.com>
 <p2bnPmfigaVwocFAEFQyTpp_w9kqm660uDRv-RD_CvI=.b0959b74-4018-4fd6-b5de-db73485ad66d@github.com>
 <bFUnj9CoMhWyFVF0m6g-Rbdwtwj9BvXM0UUvUYn5syU=.fbeb15b7-183d-4e75-a1f3-b5208ff20b26@github.com>
 <6FLXgPQyuVxwaqG40pSxeIxyCVyYgH75RWsPP353BZc=.c4e18978-acb7-4ce6-ad32-cb9d838327d9@github.com>
Message-ID: <zOAcaGYw4QmkQRvGox9dadZkkiyYDNnZKa1aGO-bWAM=.3d91569e-91c6-4ecf-94ac-5c696df191ac@github.com>

On Fri, 1 Dec 2023 15:00:50 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> @azvegint do you think it would make sense to do it in the native code or in the upper level Java code ? AND also how many times do you think it would make sense to retry provided this could be a permanent pipewire error and so it wont be sitting there re-trying with the same error forever ?  (EDIT): i see you have mentioned in the bug just 1 retry. i think it would still make sense to do something about the case where even the 2nd attempt does not succeed ie notify the caller somehow (retval/exception) that it has failed.
>
> I think it's better to do it in the native, to avoid extra native-java hops.
> 
> As for the number of extra attempts, I think one-two is enough.
> 
> Something like this (I haven't tested it thoroughly yet):
> 
> 
> diff --git a/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c b/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
> index 6a7c4124935..a7c5aadb1ae 100644
> --- a/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
> @@ -855,6 +855,32 @@ static void arrayToRectangles(JNIEnv *env,
>      (*env)->ReleaseIntArrayElements(env, boundsArray, body, 0);
>  }
>  
> +static int makeAnAttempt(
> +        const gchar *token,
> +        GdkRectangle *requestedArea,
> +        GdkRectangle *affectedScreenBounds,
> +        gint affectedBoundsLength) {
> +    if (!initScreencast(token, affectedScreenBounds, affectedBoundsLength)) {
> +        return pw.pwFd;
> +    }
> +
> +    if (!doLoop(*requestedArea)) {
> +        return RESULT_ERROR;
> +    }
> +
> +    while (!isAllDataReady()) {
> +        fp_pw_thread_loop_lock(pw.loop);
> +        fp_pw_thread_loop_wait(pw.loop);
> +        if (hasPipewireFailed) {
> +            fp_pw_thread_loop_unlock(pw.loop);
> +            doCleanup();
> +            return RESULT_ERROR;
> +        }
> +        fp_pw_thread_loop_unlock(pw.loop);
> +    }
> +    return RESULT_OK;
> +}
> +
>  /*
>   * Class:     sun_awt_screencast_ScreencastHelper
>   * Method:    closeSession
> @@ -911,25 +937,17 @@ JNIEXPORT jint JNICALL Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl
>              jx, jy, jwidth, jheight, token
>      );
>  
> -    if (!initScreencast(token, affectedScreenBounds, affectedBoundsLength)) {
> -        releaseToken(env, jtoken, token);
> -        return pw.pwFd;
> -    }
> -
> -    if (!doLoop(requestedArea)) {
> -        releaseToken(env, jtoken, token);
> -        return RESULT_ERROR;
> -    }
> +    int attemptResult = makeAnAttempt(token, &requestedArea,
> +                                      affectedScreenBounds, affectedBoundsLength);
>  
> -    while (!isAllDataReady()) {
> -        fp_pw_thread_loop_lock(pw.loop);
> -        fp_pw_thread_loop_wait(pw.loop);
> -        if (hasPipewireFailed) {
> -            fp_pw_thread_loop_unlock(pw.loop);
> +    if (attemptResult) {
> +        DEBUG_SCREENCAST("First attempt failed with %i, re-trying...\n", attemptResult);
> +        attemptResult = makeAnAttempt(token, &requestedArea,
> +                                      affectedScreenBounds, affectedBoundsLengt...

@azvegint let me have a look next week and i'll try to come up with another PR for this. the pipewire is a bit tricky to test in my experience as there are quite a few moving parts/layers there and on some error conditions it even hangs bc they chose to use no timeouts in their implementation so it just gets stuck there forever sometimes, so i would need to come up with some way/s to test this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412359619

From dnguyen at openjdk.org  Fri Dec  1 17:25:16 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 1 Dec 2023 17:25:16 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v13]
In-Reply-To: <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>
Message-ID: <_nJLqHUkRTyH9eRtWPro70q0WyUSByeVgdeWxa2noeA=.4d484e76-46d2-475d-a467-dfc1e0208afa@github.com>

On Fri, 1 Dec 2023 09:26:41 GMT, Tejesh R <tr at openjdk.org> wrote:

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

Marked as reviewed by dnguyen (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16374#pullrequestreview-1760265268

From azvegint at openjdk.org  Fri Dec  1 18:33:07 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Dec 2023 18:33:07 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api [v3]
In-Reply-To: <H7IWlO1aogmwvubrs79-M9G3EYLcXTpF1EKMmnXZMZg=.1c2a478f-9142-4660-a800-54d0f5dda873@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <H7IWlO1aogmwvubrs79-M9G3EYLcXTpF1EKMmnXZMZg=.1c2a478f-9142-4660-a800-54d0f5dda873@github.com>
Message-ID: <EDLmUD4-dCT_I-SFUsR_fo2Lko3Vl8wp_CDWHtW9Y5w=.425dab50-72b7-42f3-bdb7-767864a855d9@github.com>

On Fri, 1 Dec 2023 16:49:30 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.
>
> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320655: remove volatiles and do explicit cleanup on failure

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16794#pullrequestreview-1760366322

From azvegint at openjdk.org  Fri Dec  1 18:33:08 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 1 Dec 2023 18:33:08 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api [v3]
In-Reply-To: <zOAcaGYw4QmkQRvGox9dadZkkiyYDNnZKa1aGO-bWAM=.3d91569e-91c6-4ecf-94ac-5c696df191ac@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <Gt_7HVMdb-0gdguDlYC8ddS0j6fE19vZPlrgOm_Alz8=.da246fcd-e88f-4036-9d25-2dfd6246c616@github.com>
 <VeZslpXLMOc2EDvSFl2wmOb_VdHHN7A5Gp6F7MK9B5g=.becc5889-a79e-4ae1-af05-11bf85433b07@github.com>
 <p2bnPmfigaVwocFAEFQyTpp_w9kqm660uDRv-RD_CvI=.b0959b74-4018-4fd6-b5de-db73485ad66d@github.com>
 <bFUnj9CoMhWyFVF0m6g-Rbdwtwj9BvXM0UUvUYn5syU=.fbeb15b7-183d-4e75-a1f3-b5208ff20b26@github.com>
 <6FLXgPQyuVxwaqG40pSxeIxyCVyYgH75RWsPP353BZc=.c4e18978-acb7-4ce6-ad32-cb9d838327d9@github.com>
 <zOAcaGYw4QmkQRvGox9dadZkkiyYDNnZKa1aGO-bWAM=.3d91569e-91c6-4ecf-94ac-5c696df191ac@github.com>
Message-ID: <dDAKO8Bw8Fktd8ERRL_bmVLk1IkALIYHD2_SYBAvmWI=.13a0bd30-a8b6-433e-b894-73a057721411@github.com>

On Fri, 1 Dec 2023 16:54:34 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> I think it's better to do it in the native, to avoid extra native-java hops.
>> 
>> As for the number of extra attempts, I think one-two is enough.
>> 
>> Something like this (I haven't tested it thoroughly yet):
>> 
>> 
>> diff --git a/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c b/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
>> index 6a7c4124935..a7c5aadb1ae 100644
>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c
>> @@ -855,6 +855,32 @@ static void arrayToRectangles(JNIEnv *env,
>>      (*env)->ReleaseIntArrayElements(env, boundsArray, body, 0);
>>  }
>>  
>> +static int makeAnAttempt(
>> +        const gchar *token,
>> +        GdkRectangle *requestedArea,
>> +        GdkRectangle *affectedScreenBounds,
>> +        gint affectedBoundsLength) {
>> +    if (!initScreencast(token, affectedScreenBounds, affectedBoundsLength)) {
>> +        return pw.pwFd;
>> +    }
>> +
>> +    if (!doLoop(*requestedArea)) {
>> +        return RESULT_ERROR;
>> +    }
>> +
>> +    while (!isAllDataReady()) {
>> +        fp_pw_thread_loop_lock(pw.loop);
>> +        fp_pw_thread_loop_wait(pw.loop);
>> +        if (hasPipewireFailed) {
>> +            fp_pw_thread_loop_unlock(pw.loop);
>> +            doCleanup();
>> +            return RESULT_ERROR;
>> +        }
>> +        fp_pw_thread_loop_unlock(pw.loop);
>> +    }
>> +    return RESULT_OK;
>> +}
>> +
>>  /*
>>   * Class:     sun_awt_screencast_ScreencastHelper
>>   * Method:    closeSession
>> @@ -911,25 +937,17 @@ JNIEXPORT jint JNICALL Java_sun_awt_screencast_ScreencastHelper_getRGBPixelsImpl
>>              jx, jy, jwidth, jheight, token
>>      );
>>  
>> -    if (!initScreencast(token, affectedScreenBounds, affectedBoundsLength)) {
>> -        releaseToken(env, jtoken, token);
>> -        return pw.pwFd;
>> -    }
>> -
>> -    if (!doLoop(requestedArea)) {
>> -        releaseToken(env, jtoken, token);
>> -        return RESULT_ERROR;
>> -    }
>> +    int attemptResult = makeAnAttempt(token, &requestedArea,
>> +                                      affectedScreenBounds, affectedBoundsLength);
>>  
>> -    while (!isAllDataReady()) {
>> -        fp_pw_thread_loop_lock(pw.loop);
>> -        fp_pw_thread_loop_wait(pw.loop);
>> -        if (hasPipewireFailed) {
>> -            fp_pw_thread_loop_unlock(pw.loop);
>> +    if (attemptResult) {
>> +        DEBUG_SCREENCAST("First attempt failed with %i, re-trying...\n", attemptResult);
>> +     ...
>
> @azvegint let me have a look next week and i'll try to come up with another PR for this. the pipewire is a bit tricky to test in my experience as there are quite a few moving parts/layers there and on some error conditions it even hangs bc they chose to use no timeouts in their implementation so it just gets stuck there forever sometimes, so i would need to come up with some way/s to test this.

Sure, let's move the retries to the [8321176](https://bugs.openjdk.org/browse/JDK-8321176)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16794#discussion_r1412447547

From achung at openjdk.org  Fri Dec  1 20:35:09 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Dec 2023 20:35:09 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
Message-ID: <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>

> Added delays to stabilize test, test passes 50 times consecutively

Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:

 - updated test
 - updated test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16867/files
  - new: https://git.openjdk.org/jdk/pull/16867/files/f6a09ce3..3ab65e5b

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

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

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

From achung at openjdk.org  Fri Dec  1 20:35:10 2023
From: achung at openjdk.org (Alisen Chung)
Date: Fri, 1 Dec 2023 20:35:10 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <anEvetswj9RZTYv_EJ9w_N8OHM0mWNMXW4ltMzCTYFc=.306b1845-5b46-4318-93c1-ffcc342bfd09@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <0WMyIhY9rLL_Qfg-5sia7M8QwfnUyzJtDYE9TWyx63g=.ea76cf35-ea0c-4e6e-9393-e8fd014e4a87@github.com>
 <anEvetswj9RZTYv_EJ9w_N8OHM0mWNMXW4ltMzCTYFc=.306b1845-5b46-4318-93c1-ffcc342bfd09@github.com>
Message-ID: <C3BEIoh_AoPg_2Y9EInxCINjBrM0-vECKTWKTov8VhY=.c3ada273-91eb-4106-8790-537f260128c3@github.com>

On Wed, 29 Nov 2023 18:59:25 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/Window/Grab/GrabTest.java line 221:
>> 
>>> 219:         robot.delay(100);
>>> 220:         robot.mouseRelease(InputEvent.BUTTON1_MASK);
>>> 221:         Util.waitForIdle(robot);
>> 
>> Can be replaced with BUTTON1_DOWN_MASK.
>> 
>> Has the fix been tested on macOS 14 ?
>
> That (about macOS 14) is the important question. Why is it so unstable on macOS 14 but fine everywhere else ?
> 
> Also can't you use "setAutoDelay(100)" instead of adding all these one-off delays ?

The test passes on macOS 14

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1412547730

From serb at openjdk.org  Sat Dec  2 08:47:37 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 2 Dec 2023 08:47:37 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v7]
In-Reply-To: <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com>
Message-ID: <yWvbE0SYx4Qg5Yo75OIAY06D9MY8KbWpZdHWHVJi85Q=.472f3461-5ea8-43f8-9b79-385797826a40@github.com>

On Tue, 21 Nov 2023 08:40:40 GMT, songpv-imt <duke at openjdk.org> wrote:

>> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
>> 
>> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)
>
> songpv-imt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterJVMGetDropSuccessTest.java
>   Instead of using SYNC_LOCK to synchronize accessing the listener's fields, for better code transparency, we have placed the code that accesses the listener's fields from the main thread into the AWT Event Queue.

>The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly.

Why this issue can be reproduced in macOS 14? What was changed in that version?

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

PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1837090549

From serb at openjdk.org  Sat Dec  2 09:10:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 2 Dec 2023 09:10:36 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
Message-ID: <CEXtdgNmS0JmjT5ZBAcwHZZ9-5xQftAGHFi_5t75B0g=.b165271c-2764-462b-a6ba-de5fb4f89627@github.com>

On Fri, 1 Dec 2023 06:31:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

That code does not look like double-checked lock, it is something different. It checks/init/sets one field and then returns another one. Even if both will be marked as volatile the method may return null, since the loadedImage is set to true before init of image.

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1837095660

From aturbanov at openjdk.org  Sat Dec  2 20:58:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 2 Dec 2023 20:58:46 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v13]
In-Reply-To: <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>
Message-ID: <WfeNN8DkCZmKqhd1yytZeVQrpQXtEC1oZuyWcQc8-8I=.6502c736-99b3-40a8-8d88-b025c29dbb0c@github.com>

On Fri, 1 Dec 2023 09:26:41 GMT, Tejesh R <tr at openjdk.org> wrote:

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

src/java.desktop/share/classes/javax/swing/JTable.java line 3009:

> 3007:         else {
> 3008:             TableColumnModel cm = getColumnModel();
> 3009:             for(int i = 0; i < column; i++) {

Suggestion:

            for (int i = 0; i < column; i++) {

src/java.desktop/share/classes/javax/swing/JTable.java line 3016:

> 3014:             // adjust the x coordinate for this case.
> 3015:             final int columnWidth = cm.getColumn(column).getWidth();
> 3016:             if( !getComponentOrientation().isLeftToRight() ) {

Suggestion:

            if (!getComponentOrientation().isLeftToRight()) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1412872414
PR Review Comment: https://git.openjdk.org/jdk/pull/16374#discussion_r1412872472

From duke at openjdk.org  Sat Dec  2 22:09:09 2023
From: duke at openjdk.org (duke)
Date: Sat, 2 Dec 2023 22:09:09 GMT
Subject: Withdrawn: 8269806: Emoji rendering on Linux
In-Reply-To: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
References: <TvYUntHbfOLa-Wdbsh5lpQo2jKzPIotPlUuwsqIcERc=.75104ec2-b82b-4d41-b96b-2f7378c7a97c@github.com>
Message-ID: <7igze4XpcdGb7TWLiymlYjqLaO84hpIYpKo43zRid2M=.04232ae1-d911-4e1f-8059-6af504362c7b@github.com>

On Thu, 15 Jul 2021 17:29:01 GMT, Nikita Gubarkov <ngubarkov at openjdk.org> wrote:

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

This pull request has been closed without being integrated.

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

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

From jwaters at openjdk.org  Sun Dec  3 15:41:13 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 3 Dec 2023 15:41:13 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v39]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <ZQCLFsg0vPJoHuCnzQw6LtfgnXnLpTMCmFZuOkzn4wU=.0cd06ea9-e404-4eaa-9df3-d7826d9f87e1@github.com>

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

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

  awt_Frame.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/b9a7e02e..e0f1ce1c

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

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

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

From jwaters at openjdk.org  Sun Dec  3 15:41:16 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 3 Dec 2023 15:41:16 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v2]
In-Reply-To: <lJ7Sto8zCC9U4HpUlaEAuZL983Q5cR23FK9jkhc6Bkw=.4f76d268-3f91-458d-903f-6e52f6edcc1c@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <Qe5ihlyAofq8xiGUpBxmzNMwWzSxt7IkDq3rIteHXQA=.6742f48e-520e-476f-86c6-78d92b506ed0@github.com>
 <lJ7Sto8zCC9U4HpUlaEAuZL983Q5cR23FK9jkhc6Bkw=.4f76d268-3f91-458d-903f-6e52f6edcc1c@github.com>
Message-ID: <LyfvKYTuJEv6MCr_gzarHNY--UASikJ5Kp_ShrIYzo8=.e5b6af37-2e44-49eb-b467-d1d856f5e093@github.com>

On Wed, 9 Aug 2023 06:35:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:
>> 
>>  - Mismatched declaration in D3DGlyphCache.cpp
>>  - Fields in awt_TextComponent.cpp
>>  - reinterpret_cast needed in AccessBridgeJavaEntryPoints.cpp
>>  - Qualifiers in awt_PrintDialog.h should be removed
>>  - Likewise for awt_DnDDT.cpp
>>  - awt_ole.h include order issue in awt_DnDDS.cpp
>>  - Revert awt_ole.h
>>  - Earlier fix in awt_ole.h was not complete
>>  - Merge branch 'openjdk:master' into patch-10
>>  - Likewise for awt_Frame.cpp
>>  - ... and 12 more: https://git.openjdk.org/jdk/compare/adf193c5...51230f3d
>
> src/java.desktop/windows/native/libawt/windows/awt_Frame.cpp line 1641:
> 
>> 1639:         }
>> 1640:     }
>> 1641: 
> 
> A possible improvement later (and for a future RFE) would be to use RAII for deletion and then get rid of the labels. awt is one of the few places that uses C++ for native code, so why not.

Phil unfortunately rejected that approach, so we're on to a more manual way of deleting things here

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

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

From jwaters at openjdk.org  Sun Dec  3 16:29:15 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 3 Dec 2023 16:29:15 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v40]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <LNVNpwQMkqaOsOcqpVEwjCO2Nud_ivil-OLrpjJvxm8=.7559e47b-a63d-4961-9b13-58971a1d840d@github.com>

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

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

  awt_PrintJob.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/e0f1ce1c..aecae497

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

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

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

From jwaters at openjdk.org  Sun Dec  3 16:37:05 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 3 Dec 2023 16:37:05 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v41]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <vkq_C5x5B5nmyaOLxSSLtEqoiieUECQqbo1r48m5e4s=.48dbb94d-2dfa-438e-8081-e9b135126bbc@github.com>

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

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

  awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/aecae497..6b7ec447

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

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

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

From jwaters at openjdk.org  Sun Dec  3 16:37:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 3 Dec 2023 16:37:07 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v26]
In-Reply-To: <voQ_w619MYdQuwAhh67ohAOnRTBlkTw-wQrU4o6cfSI=.beaffa91-a232-422d-a8e1-45698f2a9a21@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <qt45xb7964rIYZEaKRNbLCeS1GbMltxfRzVkKcLLBM4=.2ce915d5-6379-4056-867e-074e387eb563@github.com>
 <4XtsPdwNattIdWDDPwNFl5uWX_GDIoVQurOK8_gp5hE=.12c78269-70d1-4a2e-9b9b-d62c8abe359d@github.com>
 <voQ_w619MYdQuwAhh67ohAOnRTBlkTw-wQrU4o6cfSI=.beaffa91-a232-422d-a8e1-45698f2a9a21@github.com>
Message-ID: <f7jLKXe2-rv_6fKpMj2_vzg6L4iH3CIxWzSPOg41ZaQ=.c473f339-7259-498b-82ba-29268eab51cc@github.com>

On Thu, 16 Nov 2023 03:44:53 GMT, Phil Race <prr at openjdk.org> wrote:

>> I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response:
>> 
>>> Back in JDK 8 when we used Visual Studio 2010, we used to not ship
>>> msvcp*.dll. This changed when I added support for building with Visual
>>> Studio 2013 [1] in JDK 9. In the patch for that bug I found this text:
>>> 
>>>+   # If building with Visual Studio 2010, we can still use
>>> _STATIC_CPPLIB to
>>>+   # avoid bundling msvcpNNN.dll. Doesn't work with newer versions of
>>> visual
>>>+   # studio.
>>> 
>>> So since we switched to Visual Studio 2013, we started to bundle
>>> msvcp*.dll. It was only ever possible to not bundle it if you built with
>>> Visual Studio 2010 (or older I suppose). It's pretty safe to say that
>>> the current mainline JDK build requires msvcp.dll to be bundled. Looking
>>> at the configure logic, configure will fail unless we find it and the
>>> copying in open/make/modules/java.base/Copy.gmk is unconditional.
>>> 
>>> /Erik
>>> 
>>> [1] https://bugs.openjdk.org/browse/JDK-8042707
>> 
>> This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such
>
>> I happened to ask around on the build-dev mailing lists about whether we include msvcp.dll with the JDK, here is Erik's response:
> 
> Yes, I saw that. It doesn't make any difference.
> Although BTW the comment points out we shouldn't be doing static linking anymore.
> 
> 
>> This may be unrelated, but I really think we should kill the std::bad_alloc hack in awt.dll as such
> 
> seems unrelated, yes, but I'd have to look at that, to see if there's a reason to touch it. Itchy fingers are  not a valid reason.

@prrace Finally finished converting all of them. Is the new style of change ok?

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

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

From jwaters at openjdk.org  Sun Dec  3 16:43:20 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 3 Dec 2023 16:43:20 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v42]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <ULwbfxJRP9rxaUy9XIr7J63iYdi_eaD0zPopkTCNtgk=.2e3bc570-481c-4be3-a4ac-642bfaa94980@github.com>

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

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

 - -Zc:stringStrings no longer needed with -permissive- flags-cflags.m4
 - Fix awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/6b7ec447..31ff0e0a

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

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

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

From jwaters at openjdk.org  Mon Dec  4 04:45:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Dec 2023 04:45:18 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v43]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <lNLyjw2VGFLRM326x2lvo97fREq-Rp95mgpIY7NynSQ=.e668250a-9078-4b3e-b1bd-e6ce04ce6407@github.com>

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

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

  Fix awt_PrintJob.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/31ff0e0a..e4bbaf0d

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

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

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

From tr at openjdk.org  Mon Dec  4 04:53:12 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 4 Dec 2023 04:53:12 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v14]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <ZUk4sTH_ZITLb9ifVUAPOcvXD4rgnb1rH4vg-2r85KI=.4e5b46e3-cfe2-440a-a185-009aa1c2785a@github.com>

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

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

  Review fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16374/files
  - new: https://git.openjdk.org/jdk/pull/16374/files/0b8ad711..dc6029e7

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

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

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

From duke at openjdk.org  Mon Dec  4 05:37:46 2023
From: duke at openjdk.org (songpv-imt)
Date: Mon, 4 Dec 2023 05:37:46 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v7]
In-Reply-To: <yWvbE0SYx4Qg5Yo75OIAY06D9MY8KbWpZdHWHVJi85Q=.472f3461-5ea8-43f8-9b79-385797826a40@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com>
 <yWvbE0SYx4Qg5Yo75OIAY06D9MY8KbWpZdHWHVJi85Q=.472f3461-5ea8-43f8-9b79-385797826a40@github.com>
Message-ID: <cNHcOh5qmhCl7Q9zh9lj9Yh39RogR_LSPsOKd58dnz8=.a423a469-7819-475a-91d3-54307c9ba36c@github.com>

On Sat, 2 Dec 2023 08:45:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> Why this issue can be reproduced in macOS 14? What was changed in that version?

I am uncertain about the exact code modifications in MacOS 14 that make this issue reproducible. Nevertheless, considering the underlying code logic, this issue could occur on any version of MacOS, contingent on timing factors, if the fix is not applied.

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

PR Comment: https://git.openjdk.org/jdk/pull/16396#issuecomment-1837874468

From psadhukhan at openjdk.org  Mon Dec  4 06:29:48 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 4 Dec 2023 06:29:48 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v14]
In-Reply-To: <ZUk4sTH_ZITLb9ifVUAPOcvXD4rgnb1rH4vg-2r85KI=.4e5b46e3-cfe2-440a-a185-009aa1c2785a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <ZUk4sTH_ZITLb9ifVUAPOcvXD4rgnb1rH4vg-2r85KI=.4e5b46e3-cfe2-440a-a185-009aa1c2785a@github.com>
Message-ID: <VUNMS5eKsKXCpNVsjSRPGNtMtKDO9w7SmwUHA--sxo4=.931847d8-f729-42f9-9860-ac48e7267808@github.com>

On Mon, 4 Dec 2023 04:53:12 GMT, Tejesh R <tr at openjdk.org> wrote:

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

Since this is about getting correct x value depending on column width, can you please confirm it works on table having columns with varying widths?

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

PR Comment: https://git.openjdk.org/jdk/pull/16374#issuecomment-1837918206

From psadhukhan at openjdk.org  Mon Dec  4 06:32:37 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 4 Dec 2023 06:32:37 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <CEXtdgNmS0JmjT5ZBAcwHZZ9-5xQftAGHFi_5t75B0g=.b165271c-2764-462b-a6ba-de5fb4f89627@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <CEXtdgNmS0JmjT5ZBAcwHZZ9-5xQftAGHFi_5t75B0g=.b165271c-2764-462b-a6ba-de5fb4f89627@github.com>
Message-ID: <4GVp56Mp0WnCRYHg4xuea03dX5FMAW6I7Ry_hmvM-3g=.73208fe7-26da-4a28-ab8f-b0279a9fbaf2@github.com>

On Sat, 2 Dec 2023 09:07:38 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> That code does not look like double-checked lock, it is something different. It checks/init/sets one field and then returns another one. Even if both will be marked as volatile the method may return null, since the loadedImage is set to true before init of image.

I think the field `loadedImage` still needs to be volatile as it is accessed multiple time even though it can be argued to be non-DCL in classical way

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1837921065

From tr at openjdk.org  Mon Dec  4 06:56:47 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 4 Dec 2023 06:56:47 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v14]
In-Reply-To: <VUNMS5eKsKXCpNVsjSRPGNtMtKDO9w7SmwUHA--sxo4=.931847d8-f729-42f9-9860-ac48e7267808@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <ZUk4sTH_ZITLb9ifVUAPOcvXD4rgnb1rH4vg-2r85KI=.4e5b46e3-cfe2-440a-a185-009aa1c2785a@github.com>
 <VUNMS5eKsKXCpNVsjSRPGNtMtKDO9w7SmwUHA--sxo4=.931847d8-f729-42f9-9860-ac48e7267808@github.com>
Message-ID: <5zYEII7UVODxpiufu9RdbclDG9frxzqaqBkxH0WStEA=.a4e07b8c-68d0-4457-aaaa-a150621a574e@github.com>

On Mon, 4 Dec 2023 06:27:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Since this is about getting correct x value depending on column width, can you please confirm it works on table having columns with varying widths?

Yes, I confirmed with varying widths and its working....

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

PR Comment: https://git.openjdk.org/jdk/pull/16374#issuecomment-1837943312

From psadhukhan at openjdk.org  Mon Dec  4 07:00:50 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Mon, 4 Dec 2023 07:00:50 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v14]
In-Reply-To: <ZUk4sTH_ZITLb9ifVUAPOcvXD4rgnb1rH4vg-2r85KI=.4e5b46e3-cfe2-440a-a185-009aa1c2785a@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <ZUk4sTH_ZITLb9ifVUAPOcvXD4rgnb1rH4vg-2r85KI=.4e5b46e3-cfe2-440a-a185-009aa1c2785a@github.com>
Message-ID: <RTEejIbpIpmYI0Uk0S0HzA2RSzPsQnTXCR8h9hkLfGg=.b52f7777-98e3-4f2b-861c-19e98900eb89@github.com>

On Mon, 4 Dec 2023 04:53:12 GMT, Tejesh R <tr at openjdk.org> wrote:

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

Marked as reviewed by psadhukhan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16374#pullrequestreview-1761704102

From jwaters at openjdk.org  Mon Dec  4 07:16:11 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Dec 2023 07:16:11 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v44]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <4jRxDXgsyED3iT7le9ohCvtmVo_QD_2HPi2gFwrdhAg=.b15acded-6fe7-4bfa-973b-f70d68b70fc4@github.com>

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

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

  Fix awt_Window.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15096/files
  - new: https://git.openjdk.org/jdk/pull/15096/files/e4bbaf0d..bed33725

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

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

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

From tr at openjdk.org  Mon Dec  4 07:33:00 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 4 Dec 2023 07:33:00 GMT
Subject: Integrated: 5108458: JTable does not properly layout its content
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: <mmAGtrodZz1da_kp6l7G03JSLXResI8bBbxIr-Q0Usw=.85deb1db-f047-4ccb-9e54-ea65e8d4f598@github.com>

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

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

This pull request has now been integrated.

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

5108458: JTable does not properly layout its content

Reviewed-by: dnguyen, aivanov, psadhukhan

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

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

From abhiscxk at openjdk.org  Mon Dec  4 09:34:14 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Mon, 4 Dec 2023 09:34:14 GMT
Subject: Integrated: 8225220: When the Tab Policy is checked, the scroll button
 direction displayed incorrectly.
In-Reply-To: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
References: <EavgMcFW_Ny0yWGvMd2taeGd4FG_fsnLaFbpgnp2yCc=.8cd68756-221a-4bbd-b43b-6f929a7c5e8e@github.com>
Message-ID: <PMkhe-V8OHGaXTeBKfYfGVD7uHd-zWIp-o_-E_jM8UM=.ad396fb9-eb40-4060-82a2-71e9454645d6@github.com>

On Fri, 10 Nov 2023 11:20:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> JTabbedPane scroll button direction was incorrect because the widget type returned while painting the arrow was `SPINNER_ARROW_BUTTON`. Added the condition check for JTabbedPane before returning the widget type and based on the tab placement set by user, appropriate widget type is returned.
> 
> Tested the CI jobs against the fix and it was green. Link attached in JBS.

This pull request has now been integrated.

Changeset: ed5b8c3a
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed5b8c3a7bb6de27ab5050db494b08d5e5dd1c44
Stats:     110 lines in 2 files changed: 109 ins; 0 del; 1 mod

8225220: When the Tab Policy is checked,the scroll button direction displayed incorrectly.

Reviewed-by: tr, psadhukhan

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

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

From jwaters at openjdk.org  Mon Dec  4 09:39:09 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Dec 2023 09:39:09 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>

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

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

 - 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
 - awt_Frame.cpp
 - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f

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

Changes: https://git.openjdk.org/jdk/pull/15096/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15096&range=44
  Stats: 615 lines in 12 files changed: 461 ins; 38 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/15096.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15096/head:pull/15096

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

From jwaters at openjdk.org  Mon Dec  4 09:48:59 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Dec 2023 09:48:59 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
Message-ID: <NoK2uFBJ1ZEcV_Q864oEWgdNBU0vPK1ytvuhjmiVkyc=.808bfdb1-6cb1-41b4-8153-cdad40fe346e@github.com>

On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
> 
>  - 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
>  - awt_Frame.cpp
>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f

Re-adding build label since this now touches build flags again

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

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

From sgehwolf at openjdk.org  Mon Dec  4 10:48:38 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Dec 2023 10:48:38 GMT
Subject: RFR: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api [v3]
In-Reply-To: <H7IWlO1aogmwvubrs79-M9G3EYLcXTpF1EKMmnXZMZg=.1c2a478f-9142-4660-a800-54d0f5dda873@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
 <H7IWlO1aogmwvubrs79-M9G3EYLcXTpF1EKMmnXZMZg=.1c2a478f-9142-4660-a800-54d0f5dda873@github.com>
Message-ID: <HEHsiUAcmtxrUoPrOkV6m6DfbpAMOCF4NtwWY-z1-KI=.f77eac13-254a-4bd2-af99-53719bd2b568@github.com>

On Fri, 1 Dec 2023 16:49:30 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.
>
> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320655: remove volatiles and do explicit cleanup on failure

32 bit test failure seems unrelated.

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

PR Comment: https://git.openjdk.org/jdk/pull/16794#issuecomment-1838319102

From duke at openjdk.org  Mon Dec  4 10:51:46 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Mon, 4 Dec 2023 10:51:46 GMT
Subject: Integrated: 8320655: awt screencast robot spin and sync issues with
 native libpipewire api
In-Reply-To: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
References: <7LMLjPVzpcCN99I7TQrTWI5RiP1U_Ndnx8SqZMFf4Hs=.2096b868-451b-43d5-ba23-816e30f9f74a@github.com>
Message-ID: <xsE0poTGgVC23EFbUDVBUSawxAs0W4a_s4kKk_rm7J4=.31d831b3-f26f-469f-9cdc-5d3a8eae9887@github.com>

On Thu, 23 Nov 2023 13:00:06 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch addresses the issues described in the https://bugs.openjdk.org/browse/JDK-8320655 by fixing the proper locking and signalling around libpipewire thread loop condition variables and also fixing libpipewire error detection and signalling and propagation to the screencast API. This makes the screencast robot stable enough to consistently make it thru the entire javax/swing jtreg suite without hanging and also significantly reduces CPU consumption as there is no longer any burning spinners since they are now waiting on related conditions proper.

This pull request has now been integrated.

Changeset: c17b8cfa
Author:    Anton Bobrov <antbob at users.noreply.github.com>
Committer: Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c17b8cfafe5a2bbe29d38cfc6793c72b0430f6ca
Stats:     32 lines in 1 file changed: 28 ins; 2 del; 2 mod

8320655: awt screencast robot spin and sync issues with native libpipewire api

Reviewed-by: azvegint

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

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

From ihse at openjdk.org  Mon Dec  4 11:32:09 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:32:09 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
Message-ID: <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>

On Mon, 4 Dec 2023 09:39:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> We should set the -permissive- flag for the Microsoft Visual C compiler, as was requested by the now backed out [JDK-8241499](https://bugs.openjdk.org/browse/JDK-8241499). Doing so makes the Visual C compiler much less accepting of ill formed code, which will improve code quality on Windows in the future.
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:
> 
>  - 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
>  - awt_Frame.cpp
>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f

make/autoconf/flags-cflags.m4 line 565:

> 563:     # The -utf-8 option sets source and execution character sets to UTF-8 to enable correct
> 564:     # compilation of all source files regardless of the active code page on Windows.
> 565:     TOOLCHAIN_CFLAGS_JVM="-nologo -MD -Zc:preprocessor -Zc:strictStrings -Zc:inline -permissive- -utf-8 -MP"

What is the rationale for removing `-Zc:strictStrings`? That seems like a step backwards. Also, this will affect *all* files compiled, both hotspot and all native JDK libraries.

If there is a single file that cannot (for some reason) be fixed to have the compiler stop complaining about const strings, that individual file should have `-Zc:strictStrings-` added to its CFLAGS.

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

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

From jwaters at openjdk.org  Mon Dec  4 11:36:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Dec 2023 11:36:18 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
 <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>
Message-ID: <cdG-CEk4-vC2aCqiOM0r9Rh4nZWgAsXGd-ZlphxpqZE=.114eaec7-5b8e-4a12-af55-3183de30d138@github.com>

On Mon, 4 Dec 2023 11:29:07 GMT, Magnus Ihse Bursie <ihse 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 78 commits:
>> 
>>  - 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
>>  - awt_Frame.cpp
>>  - ... and 68 more: https://git.openjdk.org/jdk/compare/ed5b8c3a...fda1ab0f
>
> make/autoconf/flags-cflags.m4 line 565:
> 
>> 563:     # The -utf-8 option sets source and execution character sets to UTF-8 to enable correct
>> 564:     # compilation of all source files regardless of the active code page on Windows.
>> 565:     TOOLCHAIN_CFLAGS_JVM="-nologo -MD -Zc:preprocessor -Zc:strictStrings -Zc:inline -permissive- -utf-8 -MP"
> 
> What is the rationale for removing `-Zc:strictStrings`? That seems like a step backwards. Also, this will affect *all* files compiled, both hotspot and all native JDK libraries.
> 
> If there is a single file that cannot (for some reason) be fixed to have the compiler stop complaining about const strings, that individual file should have `-Zc:strictStrings-` added to its CFLAGS.

@magicus -permissive- automatically turns on -Zc:strictStrings, so specifying it manually becomes redundant when -permissive- is also specified
https://learn.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170

> The -Zc:strictStrings option is off by default. The [-permissive-](https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-170) compiler option implicitly sets this option, but it can be overridden by using -Zc:strictStrings-

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

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

From ihse at openjdk.org  Mon Dec  4 11:47:24 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Dec 2023 11:47:24 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v45]
In-Reply-To: <cdG-CEk4-vC2aCqiOM0r9Rh4nZWgAsXGd-ZlphxpqZE=.114eaec7-5b8e-4a12-af55-3183de30d138@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
 <BdRRm7r2bF5p8f8L3SU8zN-pq_ArTojZFU0DosEDPa0=.5a83c821-d4a3-46a0-b530-3d114bf40650@github.com>
 <WJN8KSB4jQF3WPglCvTGvWKYfoY9czqaoA0L2m81-kg=.56b04dfe-e999-49bb-babe-4d5b305ff6b0@github.com>
 <cdG-CEk4-vC2aCqiOM0r9Rh4nZWgAsXGd-ZlphxpqZE=.114eaec7-5b8e-4a12-af55-3183de30d138@github.com>
Message-ID: <wlv1tqbf2AkbAwHyY1l-j5tWFVh-aD1JMUe9YL6I4sk=.ca9da060-66c1-4b26-8b7f-ee271d0e5890@github.com>

On Mon, 4 Dec 2023 11:33:09 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> make/autoconf/flags-cflags.m4 line 565:
>> 
>>> 563:     # The -utf-8 option sets source and execution character sets to UTF-8 to enable correct
>>> 564:     # compilation of all source files regardless of the active code page on Windows.
>>> 565:     TOOLCHAIN_CFLAGS_JVM="-nologo -MD -Zc:preprocessor -Zc:strictStrings -Zc:inline -permissive- -utf-8 -MP"
>> 
>> What is the rationale for removing `-Zc:strictStrings`? That seems like a step backwards. Also, this will affect *all* files compiled, both hotspot and all native JDK libraries.
>> 
>> If there is a single file that cannot (for some reason) be fixed to have the compiler stop complaining about const strings, that individual file should have `-Zc:strictStrings-` added to its CFLAGS.
>
> @magicus -permissive- automatically turns on -Zc:strictStrings, so specifying it manually becomes redundant when -permissive- is also specified
> https://learn.microsoft.com/en-us/cpp/build/reference/zc-strictstrings-disable-string-literal-type-conversion?view=msvc-170
> 
>> The -Zc:strictStrings option is off by default. The [-permissive-](https://learn.microsoft.com/en-us/cpp/build/reference/permissive-standards-conformance?view=msvc-170) compiler option implicitly sets this option, but it can be overridden by using -Zc:strictStrings-

I see. Then I guess this is okay. If/when you are finally ready for integration, and turning on -permissive-, let me know so I can take the patch for a spin in our CI systems before integration.

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

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

From aivanov at openjdk.org  Mon Dec  4 14:10:09 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Dec 2023 14:10:09 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v13]
In-Reply-To: <WfeNN8DkCZmKqhd1yytZeVQrpQXtEC1oZuyWcQc8-8I=.6502c736-99b3-40a8-8d88-b025c29dbb0c@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
 <2UCNTltZ2Fkdk7tkr4pKgeKLIa6o8Eb4adEWqOFpsCk=.637eba5f-5fde-40c6-a11b-46ea58abb8ce@github.com>
 <WfeNN8DkCZmKqhd1yytZeVQrpQXtEC1oZuyWcQc8-8I=.6502c736-99b3-40a8-8d88-b025c29dbb0c@github.com>
Message-ID: <yQYjhHpYC9EGrYtkmWARrjMvFVEI-dSp7fR94q6gwag=.47cb9e13-31a1-4e80-9a8a-00d06ffbb704@github.com>

On Sat, 2 Dec 2023 20:55:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Tejesh R has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fix
>
> src/java.desktop/share/classes/javax/swing/JTable.java line 3016:
> 
>> 3014:             // adjust the x coordinate for this case.
>> 3015:             final int columnWidth = cm.getColumn(column).getWidth();
>> 3016:             if( !getComponentOrientation().isLeftToRight() ) {
> 
> Suggestion:
> 
>             if (!getComponentOrientation().isLeftToRight()) {

@TejeshR13, @turbanoff I'd rather preserve the original style that you followed because it fits into the surrounding code even though it's different from the standard Java code conventions.

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

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

From aivanov at openjdk.org  Mon Dec  4 14:20:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Dec 2023 14:20:39 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
Message-ID: <2UZS2AxUY9DlrnZp0DRtShIGDyBCVt0hCG5tu9nVNRQ=.67c78f47-f63d-4926-bc74-a57ee2420f23@github.com>

On Fri, 1 Dec 2023 06:31:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

Based on my recent comment, the code needs updating.

Thanks @mrserb for catching another mistake.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16917#pullrequestreview-1762509285

From aivanov at openjdk.org  Mon Dec  4 14:20:43 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Dec 2023 14:20:43 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <4GVp56Mp0WnCRYHg4xuea03dX5FMAW6I7Ry_hmvM-3g=.73208fe7-26da-4a28-ab8f-b0279a9fbaf2@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <CEXtdgNmS0JmjT5ZBAcwHZZ9-5xQftAGHFi_5t75B0g=.b165271c-2764-462b-a6ba-de5fb4f89627@github.com>
 <4GVp56Mp0WnCRYHg4xuea03dX5FMAW6I7Ry_hmvM-3g=.73208fe7-26da-4a28-ab8f-b0279a9fbaf2@github.com>
Message-ID: <N7-mGqbk1hHpCYYo5p2vRIC2Wllx5s1DXvsgW3RAlt4=.b1ca4d7e-50b4-406f-8dd8-47a40a0c922a@github.com>

On Mon, 4 Dec 2023 06:30:01 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > That code does not look like double-checked lock, it is something different. It checks/init/sets one field and then returns another one. Even if both will be marked as volatile the method may return null, since the loadedImage is set to true before init of image.
> 
> I think the field `loadedImage` still needs to be volatile as it is accessed multiple time even though it can be argued to be non-DCL in classical way

Yep.

It is a DCL, essentially, but it uses a different field to protect access to another field whereas the classic DCL uses the same field that it protects.

> Even if both will be marked as volatile the method may return null, since the loadedImage is set to true before init of image.

This is correct. *Good catch!* I missed it.

*For correctness*, the assignment

https://github.com/openjdk/jdk/blob/96d69bcf8cbf1ab20b1577196120c60e072bbe78/src/java.desktop/share/classes/javax/swing/text/html/CSS.java#L2955

has to be moved below the if-statement:


                    if (!loadedImage) {
                        URL url = CSS.getURL(base, svalue);
                        if (url != null) {
                            image = new ImageIcon();
                            Image tmpImg = Toolkit.getDefaultToolkit().createImage(url);
                            if (tmpImg != null) {
                                image.setImage(tmpImg);
                            }
                        }
                        loadedImage = true;
                    }

Otherwise, the returned `image` may still be in an inconsistent state. This way, `loadedImage` is assigned `true` after `image` is initialised; that way if another thread reads `loadedImage` and its value is `true`, it can safely access `image`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1838728030

From vdyakov at openjdk.org  Mon Dec  4 17:12:39 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Mon, 4 Dec 2023 17:12:39 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
Message-ID: <2SDfFvo5Zp39GS5Qnt2NJs7j1ZtDHrz9_6ctmUlBvEU=.ecb0934c-07ae-473c-bd7c-26c239ba1857@github.com>

On Fri, 1 Dec 2023 20:35:09 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated test
>  - updated test

@azvegint @honkar-jdk  please review

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

PR Comment: https://git.openjdk.org/jdk/pull/16867#issuecomment-1839097095

From honkar at openjdk.org  Mon Dec  4 18:08:40 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 4 Dec 2023 18:08:40 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
Message-ID: <60z08FGzgbTewE7H9RUwquK4gb1Os9mS97TBKGdRHU4=.3dd2a6d8-8046-406e-a0c9-9b42bff9c9e6@github.com>

On Fri, 1 Dec 2023 20:35:09 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated test
>  - updated test

test/jdk/java/awt/Window/Grab/GrabTest.java line 77:

> 75: 
> 76:         robot = new Robot();
> 77:         robot.setAutoDelay(500);

@alisenchung The stability test fix works on macOS 14 both with setAutoDelay(500) & setAutoDelay(100).
Any reason why the autodelay is set to higher number (500 ms) here since your earlier one-off delay is 100 ms?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1414295197

From aivanov at openjdk.org  Mon Dec  4 20:43:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Dec 2023 20:43:36 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v2]
In-Reply-To: <CkKP7I-m1f-sxerCkDC02DKdOOtMU1oe9uMVRLcoFnE=.908bfc47-3070-42d8-b932-229286a3a707@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <F861qSU3Y7oeqFFrQDuBCthc_V4-nmtoA-MFOl6GRh8=.ef05929e-cea1-4669-b541-a227d6b37650@github.com>
 <nT52HzVdad5zMdK2rzWg5-dmSX4XR60hGYp-35wJTjk=.e106528e-eb1c-4481-a2e6-e595b60a1f0c@github.com>
 <CiZAb19G2TLwLKALb3mNvDICaS1usoGm9IfaI-BSI6o=.34ae7371-ee3b-4507-b187-73b84d796018@github.com>
 <vcU0eFx17JRy9I3k8q0QHdTyuvK-n7WK8vLIkY-2DRY=.1ab74d9c-5dd5-4a7e-94d4-f1f680a03fb9@github.com>
 <08NHlysHECIa2NzWIM2_IsZMxGBAjB8sUl5AIhxK4aQ=.e528a72c-d49f-4582-9466-80b762cb15ba@github.com>
 <Rh6xT9G5F3AKXcHerywrRz3A4JBILOupZ1Ek1tmVDLA=.c56d1e36-a732-4ec4-a559-5b820b322823@github.com>
 <CkKP7I-m1f-sxerCkDC02DKdOOtMU1oe9uMVRLcoFnE=.908bfc47-3070-42d8-b932-229286a3a707@github.com>
Message-ID: <p4Hkqq78dKDLxVErSFTLgnJXWOTfzM5S_uvUraSHjr0=.b9710565-6b84-4e19-9117-4a5617d0cec9@github.com>

On Thu, 23 Nov 2023 11:53:00 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>>> But the files gets deselected after selection which returns as no file selected and test failed.
>> 
>> How is it? It sounds like magic? The working directory shouldn't matter; if it does, the test isn't as stable as it should be.
>
> Surprise to me also. It failed every single time when temporary files are created in `scratch`. 
> 
>>The test isn't as stable as it should be.
> 
> Unable to trace what is missing in the test.

It took a long while for me to figure it out. What matters is whether the `File` object is created with an absolute path or not. By using `System.getProperty("java.io.tmpdir")` as the base path, you create an absolute path for the parent directory.

Yet if you use pass `null` as the first parameter (as I said, there's no system property named ".", so `tmpDir` is `null`) or use the constructor with one parameter `new File("testDir")`, the file has relative path. This causes some issues?

When you create `JFileChooser` object, you *always* pass `testDir` as its starting directory. Then, for each case, you set it once again. Here's what I see in a `PropertyChangeListener`:


>> setCurrentDirectory
directoryChanged: /home/aivanov/jdk-dev/testDir/testDir -> testDir
<< setCurrentDirectory

SelectedFileChangedProperty: /home/aivanov/jdk-dev/testDir/subDir_3 -> null
SelectedFilesChangedProperty: [Ljava.io.File;@3fed803b -> null
directoryChanged: testDir -> /home/aivanov/jdk-dev/testDir
SelectedFileChangedProperty: null -> null
SelectedFilesChangedProperty: null -> [Ljava.io.File;@1bf88ed6


This is why see a directory gets selected but then becomes unselected again.

Getting the absolute file ? `testDir = new File("testDir").getAbsoluteFile()` ? resolves this problem, and the test starts to work in the current directory. I tested it by running with jtreg, then the current directory is the `scratch` directory, and as a stand-alone app, in this case the current directory is whatever the current directory is.

So either way works as long as the starting `File` object is created with _an absolute path_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414467819

From serb at openjdk.org  Mon Dec  4 20:45:39 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 4 Dec 2023 20:45:39 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
Message-ID: <oKEw5i-cbKInLEeL_GbtsChmujlIE1glqsSl60s4jd0=.60fca2b0-c6ec-40c8-8002-a677efad6bf4@github.com>

On Fri, 1 Dec 2023 06:31:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

It is probably easy just drop the usage of loadedImage and use the image instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1839443510

From aivanov at openjdk.org  Mon Dec  4 21:05:42 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Dec 2023 21:05:42 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <nqQD3M37Dy9USTsdaWr4FhRTWK6J0VJE3KGlyWJj96E=.227906bd-a39a-4a36-9dc1-1ca0dd767a32@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <nqQD3M37Dy9USTsdaWr4FhRTWK6J0VJE3KGlyWJj96E=.227906bd-a39a-4a36-9dc1-1ca0dd767a32@github.com>
Message-ID: <dxWZQNeDZhavFRfr-pbblLfvezV_dnZjQB6chjOz1A8=.c7d1b3c1-65e0-42a1-8e64-4ec112d80abd@github.com>

On Wed, 22 Nov 2023 05:42:24 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test update

Changes requested by aivanov (Reviewer).

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 1:

> 1: /*

Since GitHub doesn't allow adding comments to lines which aren't modified:

In `doTesting`, you should get the location and dimensions of the frame on EDT (and for the button too).

The `passed` field is to be declared `volatile`: you modify it on EDT in the button listener but you read its value on main thread.

Basically, you don't need the button, you can run the code in the button action listener directly. Be sure to run it on EDT though.

The listener code can be modified to perform only one volatile write:


            public void actionPerformed(ActionEvent evt) {
                File files[] = fileChooser.getSelectedFiles();
                passed = files.length != 0;
            }

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 6972078 8319938

It's a test bug, no code in JDK is changed as the result ? the bugid shouldn't be added.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 57:

> 55:     private static File testFile;
> 56:     private static File[] SubDirs;
> 57:     private static File[] subFiles;

You don't use these arrays, they could be local variables; but even there they're not needed ? a local variable for a current file or directory is enough.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 66:

> 64:         createFilesOnlyDir();
> 65:         populateDirs();
> 66:         populateFiles();

Returning and passing the `File` object would make code flow clearer:
Suggestion:

        testDir = createFoldersOnlyDir();
        populateDirs(testDir);
        testFile = createFilesOnlyDir();
        populateFiles(testFile);


I still find `testFile` confusing because it represents a directory. What about `testDirDirs`, `testDirFiles`?

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 93:

> 91:             SubDirs[i].mkdir();
> 92:             SubDirs[i].deleteOnExit();
> 93:         }

The array is redundant:
Suggestion:

        for (int i = 0; i < 10; ++i) {
            File subDir = new File(testDir, "subDir_" + (i+1));
            subDir.mkdir();
            subDir.deleteOnExit();
        }

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 111:

> 109:                     ".txt", new File(testFile.getAbsolutePath()));
> 110:             subFiles[i].deleteOnExit();
> 111:         }

The array is redundant. I also suggest following the same pattern for creating files:
Suggestion:

        for (int i = 0; i < 10; ++i) {
            File subFile = new File(testFile, "subFiles_" + (i+1));
            subFile.createNewFile();
            subFile.deleteOnExit();
        }

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 143:

> 141:                 createAndShowUI();
> 142:                 fileChooser.setCurrentDirectory(testDir);
> 143:             });

`fileChooser.setFileSelectionMode` that you call below should be called on EDT, I suggest moving it into this block.

This applies to all `check-*` methods.

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

PR Review: https://git.openjdk.org/jdk/pull/16674#pullrequestreview-1763366339
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414493186
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414468948
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414470226
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414472923
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414474303
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414480135
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414481695

From aivanov at openjdk.org  Mon Dec  4 21:05:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Dec 2023 21:05:44 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <dxWZQNeDZhavFRfr-pbblLfvezV_dnZjQB6chjOz1A8=.c7d1b3c1-65e0-42a1-8e64-4ec112d80abd@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <nqQD3M37Dy9USTsdaWr4FhRTWK6J0VJE3KGlyWJj96E=.227906bd-a39a-4a36-9dc1-1ca0dd767a32@github.com>
 <dxWZQNeDZhavFRfr-pbblLfvezV_dnZjQB6chjOz1A8=.c7d1b3c1-65e0-42a1-8e64-4ec112d80abd@github.com>
Message-ID: <u7IfrHRxPI5j1HAiC5D4-NbI5pEaxbiJpTOnyaNmg3I=.99ea867e-1aae-4030-b9b3-cfdc13c4e136@github.com>

On Mon, 4 Dec 2023 20:52:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 143:
> 
>> 141:                 createAndShowUI();
>> 142:                 fileChooser.setCurrentDirectory(testDir);
>> 143:             });
> 
> `fileChooser.setFileSelectionMode` that you call below should be called on EDT, I suggest moving it into this block.
> 
> This applies to all `check-*` methods.

To eliminate duplicating code for disposing of the frame, create a helper method and call it from the `finally` block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1414483436

From aivanov at openjdk.org  Mon Dec  4 21:08:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 4 Dec 2023 21:08:34 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <oKEw5i-cbKInLEeL_GbtsChmujlIE1glqsSl60s4jd0=.60fca2b0-c6ec-40c8-8002-a677efad6bf4@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <oKEw5i-cbKInLEeL_GbtsChmujlIE1glqsSl60s4jd0=.60fca2b0-c6ec-40c8-8002-a677efad6bf4@github.com>
Message-ID: <CRKqrR3caJJuvfcUf8aq7YR_VROXxCk4_f_-wCT9Hjo=.8364244f-2309-447f-8eb8-48c2c4ab72ac@github.com>

On Mon, 4 Dec 2023 20:42:48 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> It is probably easy just drop the usage of loadedImage and use the image instead?

Ideally. Yet there's a corner case: if `url` is null, there's nothing to load; and it doesn't make sense to re-try, the URL won't change. If it were not for this case, the `image` field alone would do the job.

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1839476721

From serb at openjdk.org  Mon Dec  4 21:53:36 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 4 Dec 2023 21:53:36 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <CRKqrR3caJJuvfcUf8aq7YR_VROXxCk4_f_-wCT9Hjo=.8364244f-2309-447f-8eb8-48c2c4ab72ac@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <oKEw5i-cbKInLEeL_GbtsChmujlIE1glqsSl60s4jd0=.60fca2b0-c6ec-40c8-8002-a677efad6bf4@github.com>
 <CRKqrR3caJJuvfcUf8aq7YR_VROXxCk4_f_-wCT9Hjo=.8364244f-2309-447f-8eb8-48c2c4ab72ac@github.com>
Message-ID: <R1pavVMSfYZGFEf3HJnEvS65w21QlIhEV02R7AQ2e6o=.c4bc56f4-0640-4b60-b938-ff3b34e79f30@github.com>

On Mon, 4 Dec 2023 21:06:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > It is probably easy just drop the usage of loadedImage and use the image instead?
> 
> Ideally. Yet there's a corner case: if `url` is null, there's nothing to load; and it doesn't make sense to re-try, the URL won't change. If it were not for this case, the `image` field alone would do the job.

Not sure how it is expected to work, the url is a parameter and can be changed on the fly(see the usage of base in the StyleSheet.java)

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1839542420

From prr at openjdk.org  Mon Dec  4 23:31:47 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Dec 2023 23:31:47 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
Message-ID: <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>

> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
> a printer would give you null for the defaultTransform.
> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
> We have a test that would have caught it except that until recently the macOS printing implementation
> was swallowing exceptions it should not.

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

  8320443

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16773/files
  - new: https://git.openjdk.org/jdk/pull/16773/files/62b94cd7..a60c47e6

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

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

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

From prr at openjdk.org  Mon Dec  4 23:31:48 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Dec 2023 23:31:48 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <WFTpNdKA-h42jAaQN9GtIfqBYZZrn7HX2EVrDldCnF0=.fd72f92e-63e0-4bec-a450-482a1730ce3c@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <WFTpNdKA-h42jAaQN9GtIfqBYZZrn7HX2EVrDldCnF0=.fd72f92e-63e0-4bec-a450-482a1730ce3c@github.com>
Message-ID: <SrSb66ODyHEMtoL1itF-TPVeg3qfjPJIATZLeiSb-xQ=.d7656313-5d53-4d7c-8656-1a251df11979@github.com>

On Wed, 22 Nov 2023 07:49:07 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320443
>
> src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2096:
> 
>> 2094: 
>> 2095:     synchronized protected void setGraphicsConfigInfo(AffineTransform at,
>> 2096:                                             double pw, double ph) {
> 
> Let's use blessed modifiers order
> Suggestion:
> 
>     protected synchronized void setGraphicsConfigInfo(AffineTransform at,
>                                                       double pw, double ph) {

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1414628370

From prr at openjdk.org  Mon Dec  4 23:31:50 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 4 Dec 2023 23:31:50 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <kVPAfW-7IxPfv6tTeIzvOYRRD91uRhu2sxuEVglev9U=.30a49c44-4b05-423b-922d-86e3e817c11c@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <kVPAfW-7IxPfv6tTeIzvOYRRD91uRhu2sxuEVglev9U=.30a49c44-4b05-423b-922d-86e3e817c11c@github.com>
Message-ID: <rpu-9RMG9pQsD924VrB-TMJ2mWL5ms6SjRA5kzzxn8Y=.36fa213d-0847-40c0-9e25-b07a98e4e742@github.com>

On Thu, 23 Nov 2023 17:06:01 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320443
>
> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 26:
> 
>> 24: /*
>> 25:  *
>> 26:  * @bug 4276227 8320443
> 
> There's no `@test` tag, the test will not run without it.
> 
> Is it intentional?

@test is added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1414628583

From azvegint at openjdk.org  Mon Dec  4 23:36:17 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 4 Dec 2023 23:36:17 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in multiple
 Regression Test Failures on Ubuntu 23.04
Message-ID: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>

Starting with Ubuntu 23.04, we are receiving a several PropertyNotify from the window manager(Mutter on Gnome shell) with zero window insets, and only after that an actual window insets.
Our code is not ready for this, it uses the first received value. It affects all our JDK.
This did not happen before, e.g. Ubuntu 22.04 has non-zero insets from the start. 

As a result, many tests fail on Ubuntu 23.04 and 23.10.

The solution is to change these insets on the fly.

This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.

Testing looks good.

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

Commit messages:
 - tests update
 - 8305825: getBounds API returns wrong value resulting in multiple Regression Test Failures on Ubuntu 23.04

Changes: https://git.openjdk.org/jdk/pull/16960/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16960&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305825
  Stats: 37 lines in 8 files changed: 23 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16960/head:pull/16960

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

From azvegint at openjdk.org  Mon Dec  4 23:36:17 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 4 Dec 2023 23:36:17 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <3m7BOjGOzodnLWdvI_uFU_HJF8UEBuRxAWyIGuSC1Mk=.79e26925-f1d4-4129-92d6-38687cc4d1e1@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> Starting with Ubuntu 23.04, we are receiving a several PropertyNotify from the window manager(Mutter on Gnome shell) with zero window insets, and only after that an actual window insets.
> Our code is not ready for this, it uses the first received value. It affects all our JDK.
> This did not happen before, e.g. Ubuntu 22.04 has non-zero insets from the start. 
> 
> As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly.
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

test/jdk/ProblemList.txt line 461:

> 459: java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeForModalDialogTest/ConsumeForModalDialogTest.java 8302787 windows-all
> 460: java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.java 8302787 windows-all
> 461: java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java 8321303 linux-all

This intermittent issue is more reproducible after the fix, however it was there before. 
I am able to reproduce it with various JDK 11, 17, 19, 21, 22 (more info and a reproducer is available [here](https://bugs.openjdk.org/browse/JDK-8321303))

test/jdk/ProblemList.txt line 655:

> 653: javax/swing/plaf/basic/BasicTextUI/8001470/bug8001470.java 8233177 linux-all,windows-all
> 654: 
> 655: javax/swing/JFrame/MaximizeWindowTest.java 8321289 linux-all

The test was supposed to fail on Linux, but it didn't because of the misreported size. [JDK-8321289](https://bugs.openjdk.org/browse/JDK-8321289)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16960#discussion_r1414630233
PR Review Comment: https://git.openjdk.org/jdk/pull/16960#discussion_r1414630613

From achung at openjdk.org  Tue Dec  5 00:21:34 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Dec 2023 00:21:34 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <60z08FGzgbTewE7H9RUwquK4gb1Os9mS97TBKGdRHU4=.3dd2a6d8-8046-406e-a0c9-9b42bff9c9e6@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
 <60z08FGzgbTewE7H9RUwquK4gb1Os9mS97TBKGdRHU4=.3dd2a6d8-8046-406e-a0c9-9b42bff9c9e6@github.com>
Message-ID: <Je7nejO578Pj6DkOfIQDBQVOmh_wCEBuE5JXJvecong=.9278aa6e-8099-423a-943d-dbd381a6e26f@github.com>

On Mon, 4 Dec 2023 18:02:38 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated test
>>  - updated test
>
> test/jdk/java/awt/Window/Grab/GrabTest.java line 77:
> 
>> 75: 
>> 76:         robot = new Robot();
>> 77:         robot.setAutoDelay(500);
> 
> @alisenchung The stability test fix works on macOS 14 both with setAutoDelay(500) & setAutoDelay(100).
> Any reason why the autodelay is set to higher number (500 ms) here since your earlier one-off delay was 100 ms?

ive updated setAutoDelay to 100, the extra delays after creating a frame don't seem necessary because the test is passing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1414688146

From honkar at openjdk.org  Tue Dec  5 01:04:33 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 5 Dec 2023 01:04:33 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <Je7nejO578Pj6DkOfIQDBQVOmh_wCEBuE5JXJvecong=.9278aa6e-8099-423a-943d-dbd381a6e26f@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
 <60z08FGzgbTewE7H9RUwquK4gb1Os9mS97TBKGdRHU4=.3dd2a6d8-8046-406e-a0c9-9b42bff9c9e6@github.com>
 <Je7nejO578Pj6DkOfIQDBQVOmh_wCEBuE5JXJvecong=.9278aa6e-8099-423a-943d-dbd381a6e26f@github.com>
Message-ID: <CyflHAbb32iKA1gQB-5x4je6oC0hm0WbR8OEq7wWqVs=.65a3c566-32a3-40f0-b97d-686b67dcc84f@github.com>

On Tue, 5 Dec 2023 00:19:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> test/jdk/java/awt/Window/Grab/GrabTest.java line 77:
>> 
>>> 75: 
>>> 76:         robot = new Robot();
>>> 77:         robot.setAutoDelay(500);
>> 
>> @alisenchung The stability test fix works on macOS 14 both with setAutoDelay(500) & setAutoDelay(100).
>> Any reason why the autodelay is set to higher number (500 ms) here since your earlier one-off delay was 100 ms?
>
> ive updated setAutoDelay to 100, the extra delays after creating a frame don't seem necessary because the test is passing

Updated commit changes not seen on the PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1414714182

From honkar at openjdk.org  Tue Dec  5 01:04:37 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 5 Dec 2023 01:04:37 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
Message-ID: <5RUZysPnY6qBODzd8MHj2siCEfgWA28D5u84osNosKc=.c5187192-e218-4a7f-b667-08743d7ec683@github.com>

On Fri, 1 Dec 2023 20:35:09 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - updated test
>  - updated test

test/jdk/java/awt/Window/Grab/GrabTest.java line 121:

> 119: 
> 120:             f.setVisible(true);
> 121:             w.setVisible(true);

Suggestion:

            f.setVisible(true);
            w.setVisible(true);
            robot.delay(500);


Since it is unstable test, adding a delay here after the first set of frame & window are made visible might be good.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1414714397

From azvegint at openjdk.org  Tue Dec  5 01:28:34 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 01:28:34 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <CyflHAbb32iKA1gQB-5x4je6oC0hm0WbR8OEq7wWqVs=.65a3c566-32a3-40f0-b97d-686b67dcc84f@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
 <60z08FGzgbTewE7H9RUwquK4gb1Os9mS97TBKGdRHU4=.3dd2a6d8-8046-406e-a0c9-9b42bff9c9e6@github.com>
 <Je7nejO578Pj6DkOfIQDBQVOmh_wCEBuE5JXJvecong=.9278aa6e-8099-423a-943d-dbd381a6e26f@github.com>
 <CyflHAbb32iKA1gQB-5x4je6oC0hm0WbR8OEq7wWqVs=.65a3c566-32a3-40f0-b97d-686b67dcc84f@github.com>
Message-ID: <hlryWibS7bS_QoJMmYwaDdcZ45yAkK3C9TVKkcOfwBU=.a2aaeca6-1b62-40b5-b6cc-c923fb625fbd@github.com>

On Tue, 5 Dec 2023 01:01:22 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> ive updated setAutoDelay to 100, the extra delays after creating a frame don't seem necessary because the test is passing
>
> Updated changes not reflected on the PR.

I don't see the 100 ms changes either, looks like you didn't push the commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1414719975

From azvegint at openjdk.org  Tue Dec  5 01:28:37 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 01:28:37 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <5RUZysPnY6qBODzd8MHj2siCEfgWA28D5u84osNosKc=.c5187192-e218-4a7f-b667-08743d7ec683@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
 <5RUZysPnY6qBODzd8MHj2siCEfgWA28D5u84osNosKc=.c5187192-e218-4a7f-b667-08743d7ec683@github.com>
Message-ID: <In3AonEDNYFriT2Y7-NOpEdaogRnBML7DcmEQBDKShU=.9e2c3d90-5379-4d3f-b92a-23b387701ee7@github.com>

On Tue, 5 Dec 2023 01:01:50 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> Alisen Chung has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - updated test
>>  - updated test
>
> test/jdk/java/awt/Window/Grab/GrabTest.java line 121:
> 
>> 119: 
>> 120:             f.setVisible(true);
>> 121:             w.setVisible(true);
> 
> Suggestion:
> 
>             f.setVisible(true);
>             w.setVisible(true);
>             robot.delay(500);
> 
> 
> Since it is unstable test, adding a delay here after the first set of frame & window are made visible might be good.

+1, but it should be outside of the invokeAndWait. And there are other setVisible calls.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1414720493

From achung at openjdk.org  Tue Dec  5 06:26:03 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Dec 2023 06:26:03 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v3]
In-Reply-To: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
Message-ID: <klQIFthoMt0csogjSX_EGCsk3owSRaaFn02MVciQO6s=.0ea17e33-a021-4d13-934d-31e828f8a94e@github.com>

> Added delays to stabilize test, test passes 50 times consecutively

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

  updated test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16867/files
  - new: https://git.openjdk.org/jdk/pull/16867/files/3ab65e5b..625ed8a7

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

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

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

From azvegint at openjdk.org  Tue Dec  5 07:00:35 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 07:00:35 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v3]
In-Reply-To: <klQIFthoMt0csogjSX_EGCsk3owSRaaFn02MVciQO6s=.0ea17e33-a021-4d13-934d-31e828f8a94e@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <klQIFthoMt0csogjSX_EGCsk3owSRaaFn02MVciQO6s=.0ea17e33-a021-4d13-934d-31e828f8a94e@github.com>
Message-ID: <jkFWZ6EFRPR0dAwQGBCT9g6YyIZbfVwr9_lSc4_I28E=.b94ea961-f081-4c4c-a778-1a4a64d1c9ba@github.com>

On Tue, 5 Dec 2023 06:26:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test

test/jdk/java/awt/Window/Grab/GrabTest.java line 122:

> 120:             f.setVisible(true);
> 121:             w.setVisible(true);
> 122:             robot.delay(500);

This delay blocks the UI thread because it is called on EDT.
It should be called outside of the `SwingUtilities.invokeAndWait` block, e.g. before the `test()` call.

There are also other `setVisible` calls in this test that require similar delay.
Especially in cases where we try to click on a component right after showing a frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1414960840

From psadhukhan at openjdk.org  Tue Dec  5 07:59:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 5 Dec 2023 07:59:19 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking [v2]
In-Reply-To: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
Message-ID: <xli7bkozj-wgTSKTAdA7Whc6n6EiE_lwDu0ZVk9KxaU=.646301f4-8ea8-48bd-abe0-db64e74e935c@github.com>

> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

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

  Use image field for DCL

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16917/files
  - new: https://git.openjdk.org/jdk/pull/16917/files/96d69bcf..af2b9303

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

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

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

From psadhukhan at openjdk.org  Tue Dec  5 07:59:19 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 5 Dec 2023 07:59:19 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <R1pavVMSfYZGFEf3HJnEvS65w21QlIhEV02R7AQ2e6o=.c4bc56f4-0640-4b60-b938-ff3b34e79f30@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <oKEw5i-cbKInLEeL_GbtsChmujlIE1glqsSl60s4jd0=.60fca2b0-c6ec-40c8-8002-a677efad6bf4@github.com>
 <CRKqrR3caJJuvfcUf8aq7YR_VROXxCk4_f_-wCT9Hjo=.8364244f-2309-447f-8eb8-48c2c4ab72ac@github.com>
 <R1pavVMSfYZGFEf3HJnEvS65w21QlIhEV02R7AQ2e6o=.c4bc56f4-0640-4b60-b938-ff3b34e79f30@github.com>
Message-ID: <8eEZzfHu6307lqjqKp5KBbnTKMSZx0B6dWtyOLTV74I=.72ca4ab9-de6e-4461-84f4-f21bcb6d5234@github.com>

On Mon, 4 Dec 2023 21:51:15 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > > It is probably easy just drop the usage of loadedImage and use the image instead?
> > 
> > 
> > Ideally. Yet there's a corner case: if `url` is null, there's nothing to load; and it doesn't make sense to re-try, the URL won't change. If it were not for this case, the `image` field alone would do the job.
> 
> Not sure how it is expected to work, the url is a parameter and can be changed on the fly(see the usage of base in the StyleSheet.java)

Yes, seems like setBase can be used to change image URL on the fly...Modified to use image field for DCL...

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1840192317

From serb at openjdk.org  Tue Dec  5 08:43:45 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 5 Dec 2023 08:43:45 GMT
Subject: RFR: 8321325: Remove unused Java_java_awt_MenuComponent_initIDs
 function
Message-ID: <vrzPyuK7tzjy0Er0zov8GDgAgDdpVEXt6ijVmHwtqGw=.a62bd246-3af6-4de1-8923-cdd2263d8319@github.com>

The Java_java_awt_MenuComponent_initIDs function is empty on Windows and macOS, on linux it has some code but it is unused.

This issue is similar to https://bugs.openjdk.org/browse/JDK-8318091

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

Commit messages:
 - date
 - cleanup

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

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

From abhiscxk at openjdk.org  Tue Dec  5 12:17:55 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 12:17:55 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v4]
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

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

  Review comment fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16674/files
  - new: https://git.openjdk.org/jdk/pull/16674/files/9c74599c..cd69d575

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

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

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

From abhiscxk at openjdk.org  Tue Dec  5 12:18:05 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 12:18:05 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <u7IfrHRxPI5j1HAiC5D4-NbI5pEaxbiJpTOnyaNmg3I=.99ea867e-1aae-4030-b9b3-cfdc13c4e136@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <nqQD3M37Dy9USTsdaWr4FhRTWK6J0VJE3KGlyWJj96E=.227906bd-a39a-4a36-9dc1-1ca0dd767a32@github.com>
 <dxWZQNeDZhavFRfr-pbblLfvezV_dnZjQB6chjOz1A8=.c7d1b3c1-65e0-42a1-8e64-4ec112d80abd@github.com>
 <u7IfrHRxPI5j1HAiC5D4-NbI5pEaxbiJpTOnyaNmg3I=.99ea867e-1aae-4030-b9b3-cfdc13c4e136@github.com>
Message-ID: <HbSOWTfooyXDt2GNrn_70Mib2eHophBt-4Ed_U7-Efw=.8cee3ad5-4884-4572-a27a-f1cc7b978fbc@github.com>

On Mon, 4 Dec 2023 20:53:51 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 143:
>> 
>>> 141:                 createAndShowUI();
>>> 142:                 fileChooser.setCurrentDirectory(testDir);
>>> 143:             });
>> 
>> `fileChooser.setFileSelectionMode` that you call below should be called on EDT, I suggest moving it into this block.
>> 
>> This applies to all `check-*` methods.
>
> To eliminate duplicating code for disposing of the frame, create a helper method and call it from the `finally` block.

> `fileChooser.setFileSelectionMode` that you call below should be called on EDT, I suggest moving it into this block.
> 
> This applies to all `check-*` methods.

Accessed on EDT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415503095

From abhiscxk at openjdk.org  Tue Dec  5 12:18:02 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 12:18:02 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <dxWZQNeDZhavFRfr-pbblLfvezV_dnZjQB6chjOz1A8=.c7d1b3c1-65e0-42a1-8e64-4ec112d80abd@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <nqQD3M37Dy9USTsdaWr4FhRTWK6J0VJE3KGlyWJj96E=.227906bd-a39a-4a36-9dc1-1ca0dd767a32@github.com>
 <dxWZQNeDZhavFRfr-pbblLfvezV_dnZjQB6chjOz1A8=.c7d1b3c1-65e0-42a1-8e64-4ec112d80abd@github.com>
Message-ID: <fGMATH8b-pTJc3n9vpEwHaO8teNVMmucf94wv0PqemY=.14d8e65f-4b8d-4bc0-a121-2fd3e2e8751a@github.com>

On Mon, 4 Dec 2023 21:00:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test update
>
> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 1:
> 
>> 1: /*
> 
> Since GitHub doesn't allow adding comments to lines which aren't modified:
> 
> In `doTesting`, you should get the location and dimensions of the frame on EDT (and for the button too).
> 
> The `passed` field is to be declared `volatile`: you modify it on EDT in the button listener but you read its value on main thread.
> 
> Basically, you don't need the button, you can run the code in the button action listener directly. Be sure to run it on EDT though.
> 
> The listener code can be modified to perform only one volatile write:
> 
> 
>             public void actionPerformed(ActionEvent evt) {
>                 File files[] = fileChooser.getSelectedFiles();
>                 passed = files.length != 0;
>             }

`Button` and `passed` field are removed since it may not be required. The selected files are fetched in `checkResult` method.

> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 6972078 8319938
> 
> It's a test bug, no code in JDK is changed as the result ? the bugid shouldn't be added.

Updated.

> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 57:
> 
>> 55:     private static File testFile;
>> 56:     private static File[] SubDirs;
>> 57:     private static File[] subFiles;
> 
> You don't use these arrays, they could be local variables; but even there they're not needed ? a local variable for a current file or directory is enough.

Updated.

> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 66:
> 
>> 64:         createFilesOnlyDir();
>> 65:         populateDirs();
>> 66:         populateFiles();
> 
> Returning and passing the `File` object would make code flow clearer:
> Suggestion:
> 
>         testDir = createFoldersOnlyDir();
>         populateDirs(testDir);
>         testFile = createFilesOnlyDir();
>         populateFiles(testFile);
> 
> 
> I still find `testFile` confusing because it represents a directory. What about `testDirDirs`, `testDirFiles`?

Updated the var names.

> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 93:
> 
>> 91:             SubDirs[i].mkdir();
>> 92:             SubDirs[i].deleteOnExit();
>> 93:         }
> 
> The array is redundant:
> Suggestion:
> 
>         for (int i = 0; i < 10; ++i) {
>             File subDir = new File(testDir, "subDir_" + (i+1));
>             subDir.mkdir();
>             subDir.deleteOnExit();
>         }

Updated.

> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 111:
> 
>> 109:                     ".txt", new File(testFile.getAbsolutePath()));
>> 110:             subFiles[i].deleteOnExit();
>> 111:         }
> 
> The array is redundant. I also suggest following the same pattern for creating files:
> Suggestion:
> 
>         for (int i = 0; i < 10; ++i) {
>             File subFile = new File(testFile, "subFiles_" + (i+1));
>             subFile.createNewFile();
>             subFile.deleteOnExit();
>         }

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415506579
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415500444
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415500684
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415501849
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415502104
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415502358

From abhiscxk at openjdk.org  Tue Dec  5 12:18:05 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 12:18:05 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v3]
In-Reply-To: <HbSOWTfooyXDt2GNrn_70Mib2eHophBt-4Ed_U7-Efw=.8cee3ad5-4884-4572-a27a-f1cc7b978fbc@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <nqQD3M37Dy9USTsdaWr4FhRTWK6J0VJE3KGlyWJj96E=.227906bd-a39a-4a36-9dc1-1ca0dd767a32@github.com>
 <dxWZQNeDZhavFRfr-pbblLfvezV_dnZjQB6chjOz1A8=.c7d1b3c1-65e0-42a1-8e64-4ec112d80abd@github.com>
 <u7IfrHRxPI5j1HAiC5D4-NbI5pEaxbiJpTOnyaNmg3I=.99ea867e-1aae-4030-b9b3-cfdc13c4e136@github.com>
 <HbSOWTfooyXDt2GNrn_70Mib2eHophBt-4Ed_U7-Efw=.8cee3ad5-4884-4572-a27a-f1cc7b978fbc@github.com>
Message-ID: <qX1s1HyN9nhSmR9VGukSghDOHLFd4QRrj-CPkqW_Ll4=.62bf1112-6a6f-4e61-8a9e-65e82aeefbed@github.com>

On Tue, 5 Dec 2023 12:12:34 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> To eliminate duplicating code for disposing of the frame, create a helper method and call it from the `finally` block.
>
>> `fileChooser.setFileSelectionMode` that you call below should be called on EDT, I suggest moving it into this block.
>> 
>> This applies to all `check-*` methods.
> 
> Accessed on EDT.

> To eliminate duplicating code for disposing of the frame, create a helper method and call it from the `finally` block.

Updated, looks cleaner code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415503842

From aivanov at openjdk.org  Tue Dec  5 13:05:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 13:05:39 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <8eEZzfHu6307lqjqKp5KBbnTKMSZx0B6dWtyOLTV74I=.72ca4ab9-de6e-4461-84f4-f21bcb6d5234@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <oKEw5i-cbKInLEeL_GbtsChmujlIE1glqsSl60s4jd0=.60fca2b0-c6ec-40c8-8002-a677efad6bf4@github.com>
 <CRKqrR3caJJuvfcUf8aq7YR_VROXxCk4_f_-wCT9Hjo=.8364244f-2309-447f-8eb8-48c2c4ab72ac@github.com>
 <R1pavVMSfYZGFEf3HJnEvS65w21QlIhEV02R7AQ2e6o=.c4bc56f4-0640-4b60-b938-ff3b34e79f30@github.com>
 <8eEZzfHu6307lqjqKp5KBbnTKMSZx0B6dWtyOLTV74I=.72ca4ab9-de6e-4461-84f4-f21bcb6d5234@github.com>
Message-ID: <CZrXCQF1LEmlRPSerYn10yc8Ko5s8-Y6rbHQkHLTVWQ=.ada14155-4746-4387-97e3-0192d137ecf9@github.com>

On Tue, 5 Dec 2023 07:55:22 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> > > > It is probably easy just drop the usage of loadedImage and use the image instead?
> > > 
> > > 
> > > Ideally. Yet there's a corner case: if `url` is null, there's nothing to load; and it doesn't make sense to re-try, the URL won't change. If it were not for this case, the `image` field alone would do the job.
> > 
> > 
> > Not sure how it is expected to work, the url is a parameter and can be changed on the fly(see the usage of base in the StyleSheet.java)
> 
> Yes, seems like setBase can be used to change image URL on the fly...Modified to use image field for DCL...

I am against this latest change: it doesn't fix much but it would cause creating the URL each time `getImage` is called if the URL is invalid for whatever reason.

Usually, `setBase` isn't changed on the fly, it's set once when the `StyleSheet` and/or `HTMLDocument` is created. If `StyleSheet.setBase` is called to modify the base, the image needs reloading *whether it's already loaded or not* ? the latest change doesn't address this problem in any way: if the image is successfully loaded, it's what's returned even though the base has been changed; and only if the image couldn't be loaded with the old base, the image will be re-loaded again.

This is asymmetric: in one case, it's re-loaded, in another ? it isn't.

I'm for keeping the current behaviour: if the URL is invalid, the image isn't loaded and will never be for this instance of` CSS.BackgroundImage`; if the URL is valid, the image gets loaded.

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1840752465

From psadhukhan at openjdk.org  Tue Dec  5 13:32:33 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 5 Dec 2023 13:32:33 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking
In-Reply-To: <CZrXCQF1LEmlRPSerYn10yc8Ko5s8-Y6rbHQkHLTVWQ=.ada14155-4746-4387-97e3-0192d137ecf9@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <oKEw5i-cbKInLEeL_GbtsChmujlIE1glqsSl60s4jd0=.60fca2b0-c6ec-40c8-8002-a677efad6bf4@github.com>
 <CRKqrR3caJJuvfcUf8aq7YR_VROXxCk4_f_-wCT9Hjo=.8364244f-2309-447f-8eb8-48c2c4ab72ac@github.com>
 <R1pavVMSfYZGFEf3HJnEvS65w21QlIhEV02R7AQ2e6o=.c4bc56f4-0640-4b60-b938-ff3b34e79f30@github.com>
 <8eEZzfHu6307lqjqKp5KBbnTKMSZx0B6dWtyOLTV74I=.72ca4ab9-de6e-4461-84f4-f21bcb6d5234@github.com>
 <CZrXCQF1LEmlRPSerYn10yc8Ko5s8-Y6rbHQkHLTVWQ=.ada14155-4746-4387-97e3-0192d137ecf9@github.com>
Message-ID: <_4A72UaN5q64sFd9Idyw8Ub9ySbVmWAjZ4NjQLsc_A4=.a1377486-9ef6-433f-93ef-269d1a53beb6@github.com>

On Tue, 5 Dec 2023 13:02:36 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> if the URL is invalid, the image isn't loaded

if (!loadedImage) {
                        URL url = CSS.getURL(base, svalue);
                        if (url != null) {
                            image = new ImageIcon();
                            Image tmpImg = Toolkit.getDefaultToolkit().createImage(url);
                            if (tmpImg != null) {
                                image.setImage(tmpImg);
                            }
                        }
                        loadedImage = true;
                    }

As per your change, if URL is invalid ie url = null, image is not loaded but `loadedImage` is set to true so it will not give another chance to load the URL again via `CSS.getURL` just in case user decides to call setBase with a valid URL (after finding `getImage `returning null)

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1840794783

From aivanov at openjdk.org  Tue Dec  5 14:03:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 14:03:46 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v4]
In-Reply-To: <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
Message-ID: <C-g79Png8Bwdp22b2BIDVwHruDZb_xFjoFERG4DfUy4=.3117ecb8-28ef-4ed6-88ac-949b7b84cb67@github.com>

On Tue, 5 Dec 2023 12:17:55 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Changes requested by aivanov (Reviewer).

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 69:

> 67:             checkFileOnlyTest(laf, testDirFiles);
> 68:             checkDirectoriesOnlyTest(laf, testDirDirs);
> 69:             checkFilesAndDirectoriesTest(laf, testDirDirs);

So, `FILES_AND_DIRECTORIES` mode is tested with directories only. Is it intentional? It's the problem in [JDK-6972078](https://bugs.openjdk.org/browse/JDK-6972078)? that directories can't be selected.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 84:

> 82:     }
> 83: 
> 84:     private static void populateDirs(File dirsDir) {

Suggestion:

    private static void populateDirs(File parent) {

It better conveys the meaning of the parameter.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 88:

> 86:             File SubDirs = new File(dirsDir, "subDir_" + (i+1));
> 87:             SubDirs.mkdir();
> 88:             SubDirs.deleteOnExit();

Suggestion:

            File subDir = new File(dirsDir, "subDir_" + (i+1));
            subDir.mkdir();
            subDir.deleteOnExit();

It's _one_ subdirectory; local variable names start with lower-case letter in Java.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 102:

> 100:     }
> 101: 
> 102:     private static void populateFiles(File filesDir) throws Exception {

Suggestion:

    private static void populateFiles(File parent) throws Exception {

Or `parentDir`.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 111:

> 109: 
> 110:     private static void checkFileOnlyTest(UIManager.LookAndFeelInfo laf,
> 111:                                           File crntDir) throws Exception {

Suggestion:

                                          File dir) throws Exception {

Alternatively, spell out `current`; if you prefer to abbreviate, `curr` is rather standard abbreviation for ?current?. However, I think `dir` is enough, its meaning is easily inferred as it's passed to `fileChooser.setCurrentDirectory`.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 134:

> 132: 
> 133:     private static void checkDirectoriesOnlyTest(UIManager.LookAndFeelInfo laf,
> 134:                                              File crntDir) throws Exception {

Suggestion:

    private static void checkDirectoriesOnlyTest(UIManager.LookAndFeelInfo laf,
                                                 File crntDir) throws Exception {

Align the parameters, if you follow this style.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 196:

> 194:             frameLocation = fileChooser.getLocationOnScreen();
> 195:             frameWidth = frame.getWidth();
> 196:             frameHeight = frame.getHeight();

Suggestion:

            bounds = new Rectangle(fileChooser.getLocationOnScreen(),
                                   frame.getSize());

Isn't one variable enough? Moreover `frameLocation` stores the location of `fileChooser`.

Since now there's only one click location, this can be simplified further:
Suggestion:

            Point fileChooserLocation = fileChooser.getLocationOnScreen();
            fileChooserLocation.y += frame.getHeight() / 3;
            clickLocation = new Point(fileChooserLocation);


Then you modify your `clickMouse` method to accept two parameters: `Point` and `xOffset`.

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 217:

> 215:                     "empty array for LAF: " + laf.getClassName());
> 216:         }
> 217:     }

And you ignored _<q cite="https://github.com/openjdk/jdk/pull/16674#discussion_r1414493186">Be sure to run it on EDT</q>_: `fileChooser.getSelectedFiles()` is to be called on EDT.

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

PR Review: https://git.openjdk.org/jdk/pull/16674#pullrequestreview-1765091146
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415660454
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415618467
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415620215
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415620925
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415624835
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415627148
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415631687
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1415644623

From aivanov at openjdk.org  Tue Dec  5 14:12:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 14:12:35 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking [v2]
In-Reply-To: <xli7bkozj-wgTSKTAdA7Whc6n6EiE_lwDu0ZVk9KxaU=.646301f4-8ea8-48bd-abe0-db64e74e935c@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <xli7bkozj-wgTSKTAdA7Whc6n6EiE_lwDu0ZVk9KxaU=.646301f4-8ea8-48bd-abe0-db64e74e935c@github.com>
Message-ID: <OjHVmQt6xYLLxIqeZX04-Fo8yHHZ1XjH2m9gnrBleBc=.11ebfdf4-1b23-4ff1-bcf5-26795ff08fc1@github.com>

On Tue, 5 Dec 2023 07:59:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use image field for DCL

> > if the URL is invalid, the image isn't loaded
> 
> As per your change, if URL is invalid ie url = null, image is not loaded but `loadedImage` is set to true so it will not give another chance to load the URL again via `CSS.getURL` just in case user decides to call setBase with a valid URL (after finding `getImage `returning null)

Exactly! The image is **never** given a chance to load for a second time.

It is how the code has always worked.

With your proposed change, the image has a chance to re-load if and only if `url == null`. And it tries re-loading over and over again until `url` becomes non-`null`. At the same time, the change to `base` is ignored if the `url` wasn't `null`? even though the image itself may not have been loaded successfully.

I do not think this is correct or desirable.

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1840866434

From psadhukhan at openjdk.org  Tue Dec  5 14:27:41 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 5 Dec 2023 14:27:41 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking [v2]
In-Reply-To: <OjHVmQt6xYLLxIqeZX04-Fo8yHHZ1XjH2m9gnrBleBc=.11ebfdf4-1b23-4ff1-bcf5-26795ff08fc1@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <xli7bkozj-wgTSKTAdA7Whc6n6EiE_lwDu0ZVk9KxaU=.646301f4-8ea8-48bd-abe0-db64e74e935c@github.com>
 <OjHVmQt6xYLLxIqeZX04-Fo8yHHZ1XjH2m9gnrBleBc=.11ebfdf4-1b23-4ff1-bcf5-26795ff08fc1@github.com>
Message-ID: <KchfJnCVlICJgbBbmF4Xkrf6sRhXpAS2WlRXEP12Tbw=.d8ae1979-061c-42ae-886d-d4bfd2d34831@github.com>

On Tue, 5 Dec 2023 14:09:42 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > if the URL is invalid, the image isn't loaded
> > 
> > 
> > As per your change, if URL is invalid ie url = null, image is not loaded but `loadedImage` is set to true so it will not give another chance to load the URL again via `CSS.getURL` just in case user decides to call setBase with a valid URL (after finding `getImage `returning null)
> 
> Exactly! The image is **never** given a chance to load for a second time.
> 
> It is how the code has always worked.
>
But it can be a bug in the code that it never gave a chance second time..I think it should get a chance to reload the URL again in case it is invalid the 1st time so I guess the change should be the one where if url is invalid, `loadedImage ` should not be set and it will need a relook at the url (to be set by user)

                  

if (!loadedImage) {
                        URL url = CSS.getURL(base, svalue);
                        if (url != null) {
                            image = new ImageIcon();
                            Image tmpImg = Toolkit.getDefaultToolkit().createImage(url);
                            if (tmpImg != null) {
                                image.setImage(tmpImg);
                            }
                            loadedImage = true;
                        }
                    }

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1840893445

From aivanov at openjdk.org  Tue Dec  5 14:42:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 14:42:36 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking [v2]
In-Reply-To: <KchfJnCVlICJgbBbmF4Xkrf6sRhXpAS2WlRXEP12Tbw=.d8ae1979-061c-42ae-886d-d4bfd2d34831@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <xli7bkozj-wgTSKTAdA7Whc6n6EiE_lwDu0ZVk9KxaU=.646301f4-8ea8-48bd-abe0-db64e74e935c@github.com>
 <OjHVmQt6xYLLxIqeZX04-Fo8yHHZ1XjH2m9gnrBleBc=.11ebfdf4-1b23-4ff1-bcf5-26795ff08fc1@github.com>
 <KchfJnCVlICJgbBbmF4Xkrf6sRhXpAS2WlRXEP12Tbw=.d8ae1979-061c-42ae-886d-d4bfd2d34831@github.com>
Message-ID: <TEHleldcdgAr77jt6uxmWVKStJjyhfRjDvQyAtyjt8A=.489cc234-d754-4574-86ed-f1f6e422ddc4@github.com>

On Tue, 5 Dec 2023 14:24:09 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> But it can be a bug in the code that it never gave a chance second time..I think it should get a chance to reload the URL again in case it is invalid the 1st time so I guess the change should be the one where if url is invalid, `loadedImage ` should not be set and it will need a relook at the url (to be set by user)

My point is it must re-load the image **whenever base is changed**, as @mrserb pointed out.

If you want to implement this feature, submit a new bug ? it is out of scope for this issue. Better yet, just submit the new bug to document the discovered problem.

Re-loading the image if and only if the `url` is `null` is inconsistent. I strongly believe the image is to be re-loaded either *always* or *never* at all rather than sometimes.

Currently, it's in *never* mode. I am for preserving the current behaviour rather than adding a half-baked solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1840924704

From rkannathpari at openjdk.org  Tue Dec  5 15:44:33 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 5 Dec 2023 15:44:33 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix
In-Reply-To: <Sx8xe-Twvv70czoEW4Y5N6Wjm2VXpxmu14_tPWm4LbY=.f6fa57fd-6419-4b83-bd3c-a0bcc1b50df8@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
 <Sx8xe-Twvv70czoEW4Y5N6Wjm2VXpxmu14_tPWm4LbY=.f6fa57fd-6419-4b83-bd3c-a0bcc1b50df8@github.com>
Message-ID: <n1rkRG57utKClgyhfePuJFdS60Vgn28kxGCK9W9kNT4=.8a623a23-ffdd-48e3-bb3c-ff89b9fdb7cd@github.com>

On Thu, 30 Nov 2023 19:20:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hi Reviewers, 
>> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
>> 
>> Renjith.
>
> Can this patch be covered by the new test?

@mrserb ,  Thanks for the review, Could you elaborate little more or share your thought? 
As per my understanding this fix will impact only on Non ICC color profile workflow. Tried bit for making a new test but as of now its not success.  There is no samples/test case available with Non ICC profile your guidance will help here.

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

PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1841049605

From duke at openjdk.org  Tue Dec  5 16:55:48 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Tue, 5 Dec 2023 16:55:48 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling
Message-ID: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>

This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.

The real major change here however is the throw of the RuntimeException which can propagate to public 

java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:

1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.

2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.

3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.

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

Commit messages:
 - 8321176: [Screencast] make a second attempt on screencast failure, improve pipewire error handling

Changes: https://git.openjdk.org/jdk/pull/16978/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16978&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321176
  Stats: 73 lines in 3 files changed: 46 ins; 13 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/16978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16978/head:pull/16978

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

From duke at openjdk.org  Tue Dec  5 16:55:49 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Tue, 5 Dec 2023 16:55:49 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling
In-Reply-To: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
Message-ID: <O9d6pp5lu9R_R_ggAndPbQpQQSrocFnd-jCKuf-NBR8=.df9775d6-4dfd-4a7d-bb2d-f67d96e870c9@github.com>

On Tue, 5 Dec 2023 16:48:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
> 
> The real major change here however is the throw of the RuntimeException which can propagate to public 
> 
> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
> 
> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
> 
> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
> 
> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.

@azvegint please have a look and let me know what you think. i dont have access to the issue tracker so lets have a discussion here and adopt this patch accordingly if possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/16978#issuecomment-1841220599

From aivanov at openjdk.org  Tue Dec  5 17:25:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 17:25:49 GMT
Subject: Integrated: 8320303: Allow PassFailJFrame to accept single window
 creator
In-Reply-To: <j-rQt5NicpSozlOpkyvylyxN_r3FIBqLntXmmuvJ3e8=.85d33960-6e5e-4513-a6f3-fe283bbce43c@github.com>
References: <j-rQt5NicpSozlOpkyvylyxN_r3FIBqLntXmmuvJ3e8=.85d33960-6e5e-4513-a6f3-fe283bbce43c@github.com>
Message-ID: <MXrKDnisW7kmJPBnoG2nTTQfx_QB2ceJSyhsHGAEugY=.f7a893ea-579a-407e-921c-832c531ff7f6@github.com>

On Fri, 17 Nov 2023 20:01:55 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Enhance `PassFailJFrame` for single-window test UI which is the most common case so that there's no need to return `List.of`.
> 
> With this change, the lambda or method reference passed to `Builder.testUI` will return Window instead of `List<Window>` (or `List<? extends Window>`.
> 
> This change adds new functional interface `WindowCreator` which returns a single Window; the existing interface is renamed to `WindowListCreator`.
> 
> It's backwards compatible change; the [FileChooserSymLinkTest.java](https://github.com/openjdk/jdk/blob/7f47c51aced9c724dbc9b0d8cbd88c49435da460/test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java) test which uses `Builder.testUI` works without change.
> 
> It was my main concern that it will be impossible to have two interfaces where one creates a `Windows` and another ? `List<Windows>`. The Java compiler automatically selects the correct method based on the return type of the lambda expression, so that both cases are supported. The requirement to return a `List` where only one window is needed bothered me, and I finally solved it.
> 
> In addition to that, I added description to all the overloads of the `Builder.testUI` method and updated the sample in the class documentation.
> 
> Since the `PassFailJFrame` class isn't supposed to be extended, I marked it `final` to prevent anyone from doing it.

This pull request has now been integrated.

Changeset: 83ffc1ac
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83ffc1ac94b8893532d8663b9058592f1714d337
Stats:     152 lines in 1 file changed: 125 ins; 6 del; 21 mod

8320303: Allow PassFailJFrame to accept single window creator

Reviewed-by: serb

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

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

From achung at openjdk.org  Tue Dec  5 17:25:54 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Dec 2023 17:25:54 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v4]
In-Reply-To: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
Message-ID: <V6B2ICYkhZ6bPl6C5pZUUMMsLXtibeSV63oCxVl4RJA=.9c96c6fd-d002-43a2-9c77-d86cf29e944a@github.com>

> Added delays to stabilize test, test passes 50 times consecutively

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

  updated test delays

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16867/files
  - new: https://git.openjdk.org/jdk/pull/16867/files/625ed8a7..fcf3a40c

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

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

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

From achung at openjdk.org  Tue Dec  5 17:25:56 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Dec 2023 17:25:56 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v3]
In-Reply-To: <klQIFthoMt0csogjSX_EGCsk3owSRaaFn02MVciQO6s=.0ea17e33-a021-4d13-934d-31e828f8a94e@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <klQIFthoMt0csogjSX_EGCsk3owSRaaFn02MVciQO6s=.0ea17e33-a021-4d13-934d-31e828f8a94e@github.com>
Message-ID: <OEP3LEsffZcWOIT0ZZnfORIKmASNKO07jTaeREsMyO8=.9fd569ec-ee54-484b-b8f7-aeb76a127e7c@github.com>

On Tue, 5 Dec 2023 06:26:03 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test

@azvegint @honkar-jdk i've updated the test delays and added more delays after new setVisible calls in test()

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

PR Comment: https://git.openjdk.org/jdk/pull/16867#issuecomment-1841274058

From achung at openjdk.org  Tue Dec  5 17:25:57 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Dec 2023 17:25:57 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v2]
In-Reply-To: <hlryWibS7bS_QoJMmYwaDdcZ45yAkK3C9TVKkcOfwBU=.a2aaeca6-1b62-40b5-b6cc-c923fb625fbd@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <PBtYtQCsNljr_Uyh0Gsp9iQRx60globBckFZ396EGEk=.f2a45b89-2fc6-4d2f-8830-7c2f151779fd@github.com>
 <60z08FGzgbTewE7H9RUwquK4gb1Os9mS97TBKGdRHU4=.3dd2a6d8-8046-406e-a0c9-9b42bff9c9e6@github.com>
 <Je7nejO578Pj6DkOfIQDBQVOmh_wCEBuE5JXJvecong=.9278aa6e-8099-423a-943d-dbd381a6e26f@github.com>
 <CyflHAbb32iKA1gQB-5x4je6oC0hm0WbR8OEq7wWqVs=.65a3c566-32a3-40f0-b97d-686b67dcc84f@github.com>
 <hlryWibS7bS_QoJMmYwaDdcZ45yAkK3C9TVKkcOfwBU=.a2aaeca6-1b62-40b5-b6cc-c923fb625fbd@github.com>
Message-ID: <8_bKsFVk4zScNx76YYoSXApiGXzS1iMGxHcJLgiAjN4=.f8000c2b-04a3-4f0a-9e47-243a50b05fd9@github.com>

On Tue, 5 Dec 2023 01:12:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Updated changes not reflected on the PR.
>
> I don't see the 100 ms changes either, looks like you didn't push the commit.

oops! just pushed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16867#discussion_r1416030726

From aivanov at openjdk.org  Tue Dec  5 17:30:51 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 17:30:51 GMT
Subject: RFR: 8320349: Simplify FileChooserSymLinkTest.java by using
 single-window testUI [v2]
In-Reply-To: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
References: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
Message-ID: <YcCUfeb__rLRgUfxI4Su1MabdWYEC_l3KGMv5hEc6kw=.aabd9c49-d7bf-4f55-863a-c1170f8d4987@github.com>

> Update `FileChooserSymLinkTest.java` to simplify its implementation by replacing `List<Window>` with `JFrame` of its `createTestUI` which now uses `PassFailJFrame.Builder testUI(PassFailJFrame.WindowCreator)` instead of `PassFailJFrame.Builder testUI(PassFailJFrame.WindowListCreator)`.
> 
> The test works correctly with and without the update.
> 
> This PR depends on #16717.

Alexey Ivanov 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.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16718/files
  - new: https://git.openjdk.org/jdk/pull/16718/files/2f1e3150..2f1e3150

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

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

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

From azvegint at openjdk.org  Tue Dec  5 17:32:35 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 17:32:35 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v4]
In-Reply-To: <V6B2ICYkhZ6bPl6C5pZUUMMsLXtibeSV63oCxVl4RJA=.9c96c6fd-d002-43a2-9c77-d86cf29e944a@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <V6B2ICYkhZ6bPl6C5pZUUMMsLXtibeSV63oCxVl4RJA=.9c96c6fd-d002-43a2-9c77-d86cf29e944a@github.com>
Message-ID: <D443icRsWM3KgFDnPUO7u81M1CWznl75_gwShdDGqvM=.328b6816-fe1b-4d20-94b1-7067845ad721@github.com>

On Tue, 5 Dec 2023 17:25:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test delays

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16867#pullrequestreview-1765730651

From honkar at openjdk.org  Tue Dec  5 17:37:41 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 5 Dec 2023 17:37:41 GMT
Subject: RFR: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on
 the outside area didn't cause ungrab [v4]
In-Reply-To: <V6B2ICYkhZ6bPl6C5pZUUMMsLXtibeSV63oCxVl4RJA=.9c96c6fd-d002-43a2-9c77-d86cf29e944a@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
 <V6B2ICYkhZ6bPl6C5pZUUMMsLXtibeSV63oCxVl4RJA=.9c96c6fd-d002-43a2-9c77-d86cf29e944a@github.com>
Message-ID: <J6WCkUxybSNkQsLY8OWCU4QXTFTw61HjW4UznuECwyI=.eadab5df-08b4-4fcb-b996-47a505aadedb@github.com>

On Tue, 5 Dec 2023 17:25:54 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> Added delays to stabilize test, test passes 50 times consecutively
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated test delays

Fix looks good and works on older macOS as well as on macOS 14.

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

Marked as reviewed by honkar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16867#pullrequestreview-1765740688

From prr at openjdk.org  Tue Dec  5 17:38:39 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 17:38:39 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v3]
In-Reply-To: <j_fwoPLqmOT7ieaOiNEGvYFdHhUfDT1JW40iDZ8o1_Q=.0b155b54-95fe-422f-b1b2-498d72711537@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <j_fwoPLqmOT7ieaOiNEGvYFdHhUfDT1JW40iDZ8o1_Q=.0b155b54-95fe-422f-b1b2-498d72711537@github.com>
Message-ID: <5TNdQdq4vg-kkf4cH6J6GaltaC6_TcVVmULzuoCPTxw=.8ab64dd7-1395-4d0d-bb85-04a39a0e6948@github.com>

On Thu, 30 Nov 2023 18:34:18 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
>> 
>> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove doc change

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16869#pullrequestreview-1765742443

From aivanov at openjdk.org  Tue Dec  5 17:44:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 17:44:13 GMT
Subject: RFR: 8320349: Simplify FileChooserSymLinkTest.java by using
 single-window testUI [v3]
In-Reply-To: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
References: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
Message-ID: <MWz3BHaP8ejv3JIbmR0D4numqxh0Gr_4j-DgnklG5TI=.5fc5fb5a-e213-4985-b8a7-b8b72302e30e@github.com>

> Update `FileChooserSymLinkTest.java` to simplify its implementation by replacing `List<Window>` with `JFrame` of its `createTestUI` which now uses `PassFailJFrame.Builder testUI(PassFailJFrame.WindowCreator)` instead of `PassFailJFrame.Builder testUI(PassFailJFrame.WindowListCreator)`.
> 
> The test works correctly with and without the update.
> 
> This PR depends on #16717.

Alexey Ivanov 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 master
 - 8320349: Simplify FileChooserSymLinkTest.java by using single-window testUI
 - 8320303: Allow PassFailJFrame to accept single window creator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16718/files
  - new: https://git.openjdk.org/jdk/pull/16718/files/2f1e3150..fd1f53f0

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

  Stats: 104798 lines in 2382 files changed: 52240 ins; 41977 del; 10581 mod
  Patch: https://git.openjdk.org/jdk/pull/16718.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16718/head:pull/16718

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

From aivanov at openjdk.org  Tue Dec  5 17:44:13 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 17:44:13 GMT
Subject: Integrated: 8320349: Simplify FileChooserSymLinkTest.java by using
 single-window testUI
In-Reply-To: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
References: <0vCdT6O0rVN46aB4Fydvyva1z6v0UfhU-KrHubjAyT0=.d42a0b60-7a54-4f89-869e-6309e9c17199@github.com>
Message-ID: <b_jvZW4zy2u0tCwl6EGee_RbWYJr9ezqpxvvGPMRh9o=.6dbf4777-9dd8-44b3-93ea-9f6fda7737df@github.com>

On Fri, 17 Nov 2023 20:21:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> Update `FileChooserSymLinkTest.java` to simplify its implementation by replacing `List<Window>` with `JFrame` of its `createTestUI` which now uses `PassFailJFrame.Builder testUI(PassFailJFrame.WindowCreator)` instead of `PassFailJFrame.Builder testUI(PassFailJFrame.WindowListCreator)`.
> 
> The test works correctly with and without the update.
> 
> This PR depends on #16717.

This pull request has now been integrated.

Changeset: b1cb3743
Author:    Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b1cb37432a4b4a10ba68f468e4d988f2a935f198
Stats:     4 lines in 1 file changed: 0 ins; 2 del; 2 mod

8320349: Simplify FileChooserSymLinkTest.java by using single-window testUI

Reviewed-by: serb

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

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

From prr at openjdk.org  Tue Dec  5 17:49:32 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 17:49:32 GMT
Subject: RFR: 8321325: Remove unused Java_java_awt_MenuComponent_initIDs
 function
In-Reply-To: <vrzPyuK7tzjy0Er0zov8GDgAgDdpVEXt6ijVmHwtqGw=.a62bd246-3af6-4de1-8923-cdd2263d8319@github.com>
References: <vrzPyuK7tzjy0Er0zov8GDgAgDdpVEXt6ijVmHwtqGw=.a62bd246-3af6-4de1-8923-cdd2263d8319@github.com>
Message-ID: <g4tXvradCnJFwSqebO1UMdldV4bPFCEXz7YfZ_IQIK4=.ed5c8324-e1b7-4f09-8fb0-486aeefaf262@github.com>

On Tue, 5 Dec 2023 08:30:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Java_java_awt_MenuComponent_initIDs function is empty on Windows and macOS, on linux it has some code but it is unused.
> 
> This issue is similar to https://bugs.openjdk.org/browse/JDK-8318091

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16965#pullrequestreview-1765764303

From achung at openjdk.org  Tue Dec  5 17:52:48 2023
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 5 Dec 2023 17:52:48 GMT
Subject: Integrated: 8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press
 on the outside area didn't cause ungrab
In-Reply-To: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
References: <hBXiqQ2Pj-r_65JuAnULsOVe16Zbluv69D2rm8rp4Ww=.1cda9ac4-0ab5-4503-bc13-5878fde4562c@github.com>
Message-ID: <sJCyuEldMB-fef5QL08JxUNmXGDLil2w423O_f9fC3Y=.3efddea2-e5ec-4639-8c50-605dde26f370@github.com>

On Tue, 28 Nov 2023 22:34:44 GMT, Alisen Chung <achung at openjdk.org> wrote:

> Added delays to stabilize test, test passes 50 times consecutively

This pull request has now been integrated.

Changeset: db5613af
Author:    Alisen Chung <achung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db5613af89a2d4ab5a8998ad1d43384778974866
Stats:     80 lines in 1 file changed: 28 ins; 6 del; 46 mod

8317288: [macos] java/awt/Window/Grab/GrabTest.java: Press on the outside area didn't cause ungrab

Reviewed-by: honkar, azvegint

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

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

From dnguyen at openjdk.org  Tue Dec  5 18:05:49 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 5 Dec 2023 18:05:49 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v4]
In-Reply-To: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
Message-ID: <DIaVtf1E5eUgqFVTvP5lK0MVWe9gB8S17Ll20x-X_Iw=.404eb7ae-23d1-4595-bf32-da2d13c8d6ea@github.com>

> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
> 
> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.

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

  Remove additional test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16869/files
  - new: https://git.openjdk.org/jdk/pull/16869/files/9b3e68cd..d6dfe355

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

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

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

From aivanov at openjdk.org  Tue Dec  5 18:10:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 18:10:38 GMT
Subject: RFR: 8321325: Remove unused Java_java_awt_MenuComponent_initIDs
 function
In-Reply-To: <vrzPyuK7tzjy0Er0zov8GDgAgDdpVEXt6ijVmHwtqGw=.a62bd246-3af6-4de1-8923-cdd2263d8319@github.com>
References: <vrzPyuK7tzjy0Er0zov8GDgAgDdpVEXt6ijVmHwtqGw=.a62bd246-3af6-4de1-8923-cdd2263d8319@github.com>
Message-ID: <-6PmsH2oDEkEI60f4Gj6r6rWng94GXiaEDgrqLdvO7U=.0184089f-9a3f-47c4-8125-ed19e36c0ffd@github.com>

On Tue, 5 Dec 2023 08:30:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Java_java_awt_MenuComponent_initIDs function is empty on Windows and macOS, on linux it has some code but it is unused.
> 
> This issue is similar to https://bugs.openjdk.org/browse/JDK-8318091

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16965#pullrequestreview-1765802969

From aivanov at openjdk.org  Tue Dec  5 18:12:43 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 18:12:43 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v4]
In-Reply-To: <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
Message-ID: <o-ddP9ogjTX29DKDDFbJTyYoLv49ruD4VrT6KDflivk=.72d0d7c4-db2f-48b6-84e8-01bb8a935b63@github.com>

On Tue, 5 Dec 2023 12:17:55 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment fix

Is it possible to shorten the subject of the issue? It is too long and wordy, yet it doesn't add valuable context.

Ideally, the summary should be concise.

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

PR Comment: https://git.openjdk.org/jdk/pull/16674#issuecomment-1841343645

From dnguyen at openjdk.org  Tue Dec  5 18:18:53 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 5 Dec 2023 18:18:53 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5]
In-Reply-To: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
Message-ID: <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>

> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
> 
> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.

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

  Re-add test because still valid

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16869/files
  - new: https://git.openjdk.org/jdk/pull/16869/files/d6dfe355..3ee39174

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

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

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

From azvegint at openjdk.org  Tue Dec  5 18:18:54 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 18:18:54 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5]
In-Reply-To: <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>
Message-ID: <VzX-cqWCFnRyLpxA338m-kwEncfBx0ipxZIoxOfRD3k=.b6ed6628-e5dc-42d2-acbf-47addb0c9461@github.com>

On Tue, 5 Dec 2023 18:15:40 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
>> 
>> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add test because still valid

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16869#pullrequestreview-1765813614

From aivanov at openjdk.org  Tue Dec  5 18:22:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 18:22:33 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix
In-Reply-To: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
Message-ID: <R-5ml73ot8I-XncrttnFAUWJbMLKxb2hJ07kfKfK_r8=.94e6c2db-d3e1-41e5-a8e6-580a537a0a73@github.com>

On Thu, 30 Nov 2023 03:34:08 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers, 
> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
> 
> Renjith.

The fix looks good to me.

I agree with @mrserb, it would be good to create a test case. I don't have much experience with color transforms, so I don't have any pointers as to how to create one. If it takes a considerable amount of time, I guess it's fine to go without the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1841358386

From honkar at openjdk.org  Tue Dec  5 18:26:34 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 5 Dec 2023 18:26:34 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5]
In-Reply-To: <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>
Message-ID: <LYoshMmeWtYPO8yLw6yWWp4ZY3kvNeLMPOSRB4hQuAg=.5295d6e2-ec24-40b1-bcb5-664355e0cb2d@github.com>

On Tue, 5 Dec 2023 18:18:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
>> 
>> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add test because still valid

@DamonGuy Reverted changes fixes the issue. Since you are reverting https://github.com/openjdk/jdk/pull/12520, shouldn't the corresponding test HtmlButtonWithTextAndIcon.java be reverted too? 
Copyright years need to be updated for some files.

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

PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1841363829

From aivanov at openjdk.org  Tue Dec  5 18:33:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 18:33:34 GMT
Subject: RFR: 8320365: IPPPrintService.getAttributes() causes blanket
 re-initialisation
In-Reply-To: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
References: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
Message-ID: <j-vgh2tgD2CINQnLDq0n6dblMO2vDXpmv94Ljr-5WW4=.d3b4c308-31c3-4c39-a897-07f870bbaf4b@github.com>

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

> Whilst reviewing the fix for https://bugs.openjdk.org/browse/JDK-7001133 I realised that although the proposed
> changes there may help, the problem would be inconsequential except that if anything causes an app to
> call PrintService.getAttributes()  we will continually be re-initialising attributes, which causes IPPPrintService
> to keep creating new instances of CUPSPrinter which are then discarded and over-written.
> So update the implementation to only re-initialise the relevant attributes.

Looks good to me.

Could you update the copyright year in `IPPPrintService.java`?

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16752#pullrequestreview-1765850140

From abhiscxk at openjdk.org  Tue Dec  5 18:34:52 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 18:34:52 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v5]
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <xA7Id5Qc5FM731EnvT0DbTCYvtV3s3P33IKwyHQLPFk=.951cd94f-c7ee-4df5-88c3-079634daac90@github.com>

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

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

  Access on EDT and few changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16674/files
  - new: https://git.openjdk.org/jdk/pull/16674/files/cd69d575..aa034e9a

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

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

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

From abhiscxk at openjdk.org  Tue Dec  5 18:34:54 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 18:34:54 GMT
Subject: RFR: 8319938:
 com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array for LAF:
 javax.swing.plaf.metal.MetalLookAndFeel" [v4]
In-Reply-To: <o-ddP9ogjTX29DKDDFbJTyYoLv49ruD4VrT6KDflivk=.72d0d7c4-db2f-48b6-84e8-01bb8a935b63@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
 <o-ddP9ogjTX29DKDDFbJTyYoLv49ruD4VrT6KDflivk=.72d0d7c4-db2f-48b6-84e8-01bb8a935b63@github.com>
Message-ID: <unDk7KP7qHVg1_6yKz2C5AbZwc7BCj_gKCAnYpI5bMY=.e3cdf3b9-6e27-413c-870c-9c69ebeecc5f@github.com>

On Tue, 5 Dec 2023 18:09:39 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> Is it possible to shorten the subject of the issue? It is too long and wordy, yet it doesn't add valuable context.
> 
> Ideally, the summary should be concise.

@aivanov-jdk Updated the suggested changes,

> Is it possible to shorten the subject of the issue? It is too long and wordy, yet it doesn't add valuable context.
> 
> Ideally, the summary should be concise.

Yeah sure, it can be changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16674#issuecomment-1841380018
PR Comment: https://git.openjdk.org/jdk/pull/16674#issuecomment-1841380641

From abhiscxk at openjdk.org  Tue Dec  5 18:38:40 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 18:38:40 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v4]
In-Reply-To: <C-g79Png8Bwdp22b2BIDVwHruDZb_xFjoFERG4DfUy4=.3117ecb8-28ef-4ed6-88ac-949b7b84cb67@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
 <C-g79Png8Bwdp22b2BIDVwHruDZb_xFjoFERG4DfUy4=.3117ecb8-28ef-4ed6-88ac-949b7b84cb67@github.com>
Message-ID: <00VdJhG5jIO3PtaPRYdPsP03EFIvZdeu2u0oZ6vBizo=.5ceb917b-0694-43b1-ab50-71618700c300@github.com>

On Tue, 5 Dec 2023 14:00:33 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> So, `FILES_AND_DIRECTORIES` mode is tested with directories only. Is it intentional? It's the problem in [JDK-6972078](https://bugs.openjdk.org/browse/JDK-6972078)? that directories can't be selected.

Yes, it is tested with directories only. 

> Is it intentional? It's the problem in [JDK-6972078](https://bugs.openjdk.org/browse/JDK-6972078)? that directories can't be selected.

Not intentional though. Thought of creating a single folder with the mix of files and directories initially but getting the location of files in `FILES_ONLY` mode was an issue in different LAF. So, created separate folders for `directories` and `files` and tested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1416127466

From abhiscxk at openjdk.org  Tue Dec  5 18:44:44 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 18:44:44 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v4]
In-Reply-To: <C-g79Png8Bwdp22b2BIDVwHruDZb_xFjoFERG4DfUy4=.3117ecb8-28ef-4ed6-88ac-949b7b84cb67@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
 <C-g79Png8Bwdp22b2BIDVwHruDZb_xFjoFERG4DfUy4=.3117ecb8-28ef-4ed6-88ac-949b7b84cb67@github.com>
Message-ID: <8DHLD1mCJOa5SHnJGxEyb4UqXlQsCmonx7B8Jd4KZVI=.35fcf78b-72ed-4637-bbe7-28a088ab347c@github.com>

On Tue, 5 Dec 2023 13:49:44 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comment fix
>
> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 217:
> 
>> 215:                     "empty array for LAF: " + laf.getClassName());
>> 216:         }
>> 217:     }
> 
> And you ignored _<q cite="https://github.com/openjdk/jdk/pull/16674#discussion_r1414493186">Be sure to run it on EDT</q>_: `fileChooser.getSelectedFiles()` is to be called on EDT.

I missed here to access `fileChooser.getSelectedFiles()` on EDT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1416134809

From azvegint at openjdk.org  Tue Dec  5 18:46:34 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 18:46:34 GMT
Subject: RFR: 8320365: IPPPrintService.getAttributes() causes blanket
 re-initialisation
In-Reply-To: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
References: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
Message-ID: <Qwk8Bh7Q4FBik_iLCIJRFQ1Tg3soz4ohGoXV01RbJaY=.672bda08-5455-4701-8123-1c82f5a30de5@github.com>

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

> Whilst reviewing the fix for https://bugs.openjdk.org/browse/JDK-7001133 I realised that although the proposed
> changes there may help, the problem would be inconsequential except that if anything causes an app to
> call PrintService.getAttributes()  we will continually be re-initialising attributes, which causes IPPPrintService
> to keep creating new instances of CUPSPrinter which are then discarded and over-written.
> So update the implementation to only re-initialise the relevant attributes.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16752#pullrequestreview-1765871784

From aivanov at openjdk.org  Tue Dec  5 19:02:40 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 19:02:40 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v5]
In-Reply-To: <xA7Id5Qc5FM731EnvT0DbTCYvtV3s3P33IKwyHQLPFk=.951cd94f-c7ee-4df5-88c3-079634daac90@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <xA7Id5Qc5FM731EnvT0DbTCYvtV3s3P33IKwyHQLPFk=.951cd94f-c7ee-4df5-88c3-079634daac90@github.com>
Message-ID: <I1kcVLwP0WKduQrYljYjT7Jn1cIaVR4kqvkAOQke3sI=.94811c67-8f5a-4d74-aae8-017234948953@github.com>

On Tue, 5 Dec 2023 18:34:52 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Access on EDT and few changes

`ActionEvent` and `ActionListener` aren't used any more, remove them, please.

Could you also update the copyright year in the file?

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 210:

> 208:     private static void checkResult(UIManager.LookAndFeelInfo laf) throws Exception {
> 209:         SwingUtilities.invokeAndWait(() -> {
> 210:             File files[] = fileChooser.getSelectedFiles();

Suggestion:

            File[] files = fileChooser.getSelectedFiles();

Let's use Java-style array declaration.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16674#pullrequestreview-1765897404
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1416152081

From dnguyen at openjdk.org  Tue Dec  5 19:11:48 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 5 Dec 2023 19:11:48 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v6]
In-Reply-To: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
Message-ID: <P3zEHZa0kNwUzilwmdonmmLSizhcUCk0xjIcH_uJ6t0=.94cb9be3-b95c-4953-a5f0-6629005711d1@github.com>

> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
> 
> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.

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

  Update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16869/files
  - new: https://git.openjdk.org/jdk/pull/16869/files/3ee39174..5cbd532a

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

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

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

From dnguyen at openjdk.org  Tue Dec  5 19:11:50 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 5 Dec 2023 19:11:50 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5]
In-Reply-To: <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>
Message-ID: <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com>

On Tue, 5 Dec 2023 18:18:53 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
>> 
>> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-add test because still valid

> @DamonGuy Reverted changes fixes the issue. Since you are reverting #12520, shouldn't the corresponding test HtmlButtonWithTextAndIcon.java be reverted too? Copyright years need to be updated for some files.

Alexander brought up the same question. After discussion, we decided to keep the test. The test is still valid & passes, so we could leave it in.

I also have updated the copyright year for BasicButtonUI. I believe that's the only case of copyright years that needs to be updated.

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

PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1841450104
PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1841453725

From abhiscxk at openjdk.org  Tue Dec  5 19:21:52 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 19:21:52 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v6]
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <zDzkkB-Xt8h5xfF4OxTqim7PBNaTaypoa_JqA47-yP4=.534d2f51-0f7c-4a0b-afc4-48936b489b5c@github.com>

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

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

  Remove unused imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16674/files
  - new: https://git.openjdk.org/jdk/pull/16674/files/aa034e9a..25965f33

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

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

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

From honkar at openjdk.org  Tue Dec  5 19:22:44 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 5 Dec 2023 19:22:44 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v6]
In-Reply-To: <P3zEHZa0kNwUzilwmdonmmLSizhcUCk0xjIcH_uJ6t0=.94cb9be3-b95c-4953-a5f0-6629005711d1@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <P3zEHZa0kNwUzilwmdonmmLSizhcUCk0xjIcH_uJ6t0=.94cb9be3-b95c-4953-a5f0-6629005711d1@github.com>
Message-ID: <vq2YNe8f0i8efWUTQ21TOER3YYTBiUrogX92E2Xw0SQ=.9594a2b0-0039-45ee-b97e-6b69d7cd8465@github.com>

On Tue, 5 Dec 2023 19:11:48 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
>> 
>> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.
>
> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year

Marked as reviewed by honkar (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16869#pullrequestreview-1765936615

From honkar at openjdk.org  Tue Dec  5 19:22:46 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 5 Dec 2023 19:22:46 GMT
Subject: RFR: 8318590: JButton ignores margin when painting HTML text [v5]
In-Reply-To: <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
 <M6uEbYCY7nLfcj_rx34bYAe4OLcHgw9QH7xd485eU-Y=.497a672f-96e2-4060-a40c-c745c3eff07a@github.com>
 <5LcDM9RyprALVI-ORxap7LCRQiNF3xtAHMqenYUKzXY=.0e733ade-053b-4210-895c-3bbceb4aefdd@github.com>
Message-ID: <Gz199fTkl0QyY0sbUx4KEzEMwOh9q7u2QvDFjejfIOo=.efbb9b66-2ccc-4619-867a-4277a18cb729@github.com>

On Tue, 5 Dec 2023 19:05:12 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> > @DamonGuy Reverted changes fixes the issue. Since you are reverting #12520, shouldn't the corresponding test HtmlButtonWithTextAndIcon.java be reverted too? Copyright years need to be updated for some files.
> 
> Alexander brought up the same question. After discussion, we decided to keep the test. The test is still valid & passes, so we could leave it in.

So this fix https://github.com/openjdk/jdk/pull/12520 was due to a prior fix https://github.com/openjdk/jdk/pull/8407 but the test remains valid in original case as well. Makes sense now as to why HtmlButtonWithTextAndIcon.java is retained.

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

PR Comment: https://git.openjdk.org/jdk/pull/16869#issuecomment-1841471863

From dnguyen at openjdk.org  Tue Dec  5 19:28:43 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 5 Dec 2023 19:28:43 GMT
Subject: Integrated: 8318590: JButton ignores margin when painting HTML text
In-Reply-To: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
References: <G2h0fPeboC8ddh5hNZY-e0wljjYgWAxi4DMmiAip8BE=.1ac79dc3-fcfd-4732-96d1-6af432d82e7c@github.com>
Message-ID: <CPNYqdBvGlTfm3DhS7wRmHNH33Ucfs0cGDUQKsWwb4E=.6bb51de8-8fe3-4036-bbfc-8b03af88f5dc@github.com>

On Tue, 28 Nov 2023 23:40:45 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

> The initial issue was a padding issue for JButton when HTML content was set as the button's text. [JDK-8282772](https://bugs.openjdk.org/browse/JDK-8282772), [JDK-8015854](https://bugs.openjdk.org/browse/JDK-8015854), and [JDK-8302173](https://bugs.openjdk.org/browse/JDK-8302173) are the issues related to the fix. The initial bug report was for Metal L&F, since it has a drastically different button margin from the rest (2, 14, 2, 14). This left and right margin of 14px led to the initial bug report. However, it was determined that the issue was not an issue, and instead, a problem with the reporter's implementation since they weren't aware of the difference in Metal's button margins versus other L&Fs.
> 
> This PR reverts these changes since it was determined in [this PR](https://github.com/JFormDesigner/FlatLaf/issues/746) that the fix causes a new issue regarding JButton contents' positioning.

This pull request has now been integrated.

Changeset: acaf2c8d
Author:    Damon Nguyen <dnguyen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/acaf2c8dcfd5235f758af2fe3e308b72263113e4
Stats:     193 lines in 4 files changed: 8 ins; 177 del; 8 mod

8318590: JButton ignores margin when painting HTML text

Reviewed-by: prr, azvegint, honkar

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

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

From aivanov at openjdk.org  Tue Dec  5 19:32:40 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 19:32:40 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v6]
In-Reply-To: <zDzkkB-Xt8h5xfF4OxTqim7PBNaTaypoa_JqA47-yP4=.534d2f51-0f7c-4a0b-afc4-48936b489b5c@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <zDzkkB-Xt8h5xfF4OxTqim7PBNaTaypoa_JqA47-yP4=.534d2f51-0f7c-4a0b-afc4-48936b489b5c@github.com>
Message-ID: <mMN8wOVLxvM7bvjzI9ADHbso2lb-xBOv3-WwUglxUfg=.e6574a6a-bd7e-440d-a1a2-3ae3e63d025d@github.com>

On Tue, 5 Dec 2023 19:21:52 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

Changes requested by aivanov (Reviewer).

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 2:

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

Suggestion:

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

You always preserve the first year.

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

PR Review: https://git.openjdk.org/jdk/pull/16674#pullrequestreview-1765952402
PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1416183017

From aivanov at openjdk.org  Tue Dec  5 19:32:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 19:32:41 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v4]
In-Reply-To: <00VdJhG5jIO3PtaPRYdPsP03EFIvZdeu2u0oZ6vBizo=.5ceb917b-0694-43b1-ab50-71618700c300@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <BkwKbU2cNNrYZNeLEXzLqRyk-wgpAJbRp8oAghSheTQ=.8c69d222-9bb7-4610-ab57-afc2ab198622@github.com>
 <C-g79Png8Bwdp22b2BIDVwHruDZb_xFjoFERG4DfUy4=.3117ecb8-28ef-4ed6-88ac-949b7b84cb67@github.com>
 <00VdJhG5jIO3PtaPRYdPsP03EFIvZdeu2u0oZ6vBizo=.5ceb917b-0694-43b1-ab50-71618700c300@github.com>
Message-ID: <ANU7YGgnmsZg8R5CeT26k9I3bBj5kfeb1qw7u62Bk74=.01dd3e77-e56a-4b6c-bc73-be14ca9d954e@github.com>

On Tue, 5 Dec 2023 18:36:13 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> > Is it intentional? It's the problem in [JDK-6972078](https://bugs.openjdk.org/browse/JDK-6972078)? that directories can't be selected.
> 
> Not intentional though. Thought of creating a single folder with the mix of files and directories initially but getting the location of files in `FILES_ONLY` mode was an issue in different LAF. So, created separate folders for `directories` and `files` and tested.

It's fine as long as the original issue is reproducible with directories only too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1416183438

From abhiscxk at openjdk.org  Tue Dec  5 19:35:50 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Tue, 5 Dec 2023 19:35:50 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v7]
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

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

  Copyright year update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16674/files
  - new: https://git.openjdk.org/jdk/pull/16674/files/25965f33..ee6d003b

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

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

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

From aivanov at openjdk.org  Tue Dec  5 19:50:45 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 19:50:45 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
Message-ID: <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>

On Mon, 4 Dec 2023 23:31:47 GMT, Phil Race <prr at openjdk.org> wrote:

>> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
>> a printer would give you null for the defaultTransform.
>> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
>> We have a test that would have caught it except that until recently the macOS printing implementation
>> was swallowing exceptions it should not.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320443

Could you also update the copyright year in `CPrinterJob.java` and `PrinterDevice.java`?

src/java.desktop/share/classes/sun/print/RasterPrinterJob.java line 2096:

> 2094: 
> 2095:     protected synchronized void setGraphicsConfigInfo(AffineTransform at,
> 2096:                                             double pw, double ph) {

Suggestion:

    protected synchronized void setGraphicsConfigInfo(AffineTransform at,
                                                      double pw, double ph) {

To preserve alignment.

test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 30:

> 28:  * @summary Checks that the PrinterGraphics is for a Printer GraphicsDevice.
> 29:  * Test doesn't run unless there's a printer on the system.
> 30:  * @key printer

Minor: we agreed to put `@key` after `@bug`.

test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 52:

> 50: public class PrinterDevice implements Printable {
> 51: 
> 52:     static volatile boolean failed = false;

Is it really needed? In all the cases where you assign `true` to the `failed` field, you also explicitly throw an exception, which is enough to fail the test.

test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 71:

> 69:         if (failed) {
> 70:             throw new RuntimeException("Test failed but no exception propagated.");
> 71:         }

A comment that `pj.print` should not throw exception would suffice, even though it's implied by jtreg any way.

This statement is essentially unreachable if `failed` is set to `true`.

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

Changes requested by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16773#pullrequestreview-1765958594
PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416186891
PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416198629
PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416195194
PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416196288

From aivanov at openjdk.org  Tue Dec  5 19:53:40 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 19:53:40 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v7]
In-Reply-To: <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
Message-ID: <Rd43gvJt76H1nuAX6vvC_RRtNQuj3JMuwEXvMrsI5VY=.6ed378ad-6a05-4f94-a72b-7126bcacc6de@github.com>

On Tue, 5 Dec 2023 19:35:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

Marked as reviewed by aivanov (Reviewer).

Pay attention to the warning displayed by the bot: retarget the bug in JBS to 22 if you're going to integrate before the fork occurs.

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

PR Review: https://git.openjdk.org/jdk/pull/16674#pullrequestreview-1765984198
PR Comment: https://git.openjdk.org/jdk/pull/16674#issuecomment-1841515999

From azvegint at openjdk.org  Tue Dec  5 20:09:35 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 20:09:35 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
 <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
Message-ID: <izscYoxCP-adqZ5lE4SM0AH2wKpQCPntFCFap9q2Ciw=.116ffca4-a5fd-434a-9644-77d836651dee@github.com>

On Tue, 5 Dec 2023 19:41:54 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320443
>
> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 52:
> 
>> 50: public class PrinterDevice implements Printable {
>> 51: 
>> 52:     static volatile boolean failed = false;
> 
> Is it really needed? In all the cases where you assign `true` to the `failed` field, you also explicitly throw an exception, which is enough to fail the test.

It is to test the "the macOS printing implementation was swallowing exceptions it should not."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416221561

From prr at openjdk.org  Tue Dec  5 20:13:50 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 20:13:50 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v3]
In-Reply-To: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
Message-ID: <v5I1iz_6FUUJuD9gotm-J_NNbp7dx5BQrZbLGl7QLxk=.0121dad7-df38-4c16-9fc2-9b96e5a4fe64@github.com>

> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
> a printer would give you null for the defaultTransform.
> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
> We have a test that would have caught it except that until recently the macOS printing implementation
> was swallowing exceptions it should not.

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

  8320443

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16773/files
  - new: https://git.openjdk.org/jdk/pull/16773/files/a60c47e6..5a463312

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

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

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

From prr at openjdk.org  Tue Dec  5 20:13:54 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 20:13:54 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
 <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
Message-ID: <VsNaaQyQoyS5Eg-3BbhfDg9IEe1ARtPKwdfTtU9cHqA=.372b628f-ca92-4c9c-bb00-a7e95695865f@github.com>

On Tue, 5 Dec 2023 19:45:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320443
>
> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 30:
> 
>> 28:  * @summary Checks that the PrinterGraphics is for a Printer GraphicsDevice.
>> 29:  * Test doesn't run unless there's a printer on the system.
>> 30:  * @key printer
> 
> Minor: we agreed to put `@key` after `@bug`.

ok ..

> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 71:
> 
>> 69:         if (failed) {
>> 70:             throw new RuntimeException("Test failed but no exception propagated.");
>> 71:         }
> 
> A comment that `pj.print` should not throw exception would suffice, even though it's implied by jtreg any way.
> 
> This statement is essentially unreachable if `failed` is set to `true`.

On JDK 17 and earlier you will reach this line with this test as written
And without that exception, the test would pass when it should fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416216067
PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416222142

From prr at openjdk.org  Tue Dec  5 20:13:56 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 20:13:56 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <izscYoxCP-adqZ5lE4SM0AH2wKpQCPntFCFap9q2Ciw=.116ffca4-a5fd-434a-9644-77d836651dee@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
 <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
 <izscYoxCP-adqZ5lE4SM0AH2wKpQCPntFCFap9q2Ciw=.116ffca4-a5fd-434a-9644-77d836651dee@github.com>
Message-ID: <hdaO1Ilxykj5NdQIXKtl0QVKwAAY9geSvqSZEToOF2A=.aec280f2-ee9e-45ac-8843-6f9a0af6d6bc@github.com>

On Tue, 5 Dec 2023 20:07:15 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 52:
>> 
>>> 50: public class PrinterDevice implements Printable {
>>> 51: 
>>> 52:     static volatile boolean failed = false;
>> 
>> Is it really needed? In all the cases where you assign `true` to the `failed` field, you also explicitly throw an exception, which is enough to fail the test.
>
> It is to test the "the macOS printing implementation was swallowing exceptions it should not."

Not sufficient if something catches the exception as used to happen

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416222101

From prr at openjdk.org  Tue Dec  5 20:25:34 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 20:25:34 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling
In-Reply-To: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
Message-ID: <xOWfXpxBpwBiSCdgXzK3rPy7YFeH0qc5ccd_jg6u-8M=.3c9f4727-1e0f-4a38-b930-caf1f7cc93ab@github.com>

On Tue, 5 Dec 2023 16:48:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
> 
> The real major change here however is the throw of the RuntimeException which can propagate to public 
> 
> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
> 
> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
> 
> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
> 
> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.

src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 223:

> 221:         } else if (retVal == ERROR) {
> 222:             throw new RuntimeException(
> 223:                 "Screen capture has failed due to desktop environment error");

Please remove this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1416236955

From aivanov at openjdk.org  Tue Dec  5 20:28:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 20:28:35 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <VsNaaQyQoyS5Eg-3BbhfDg9IEe1ARtPKwdfTtU9cHqA=.372b628f-ca92-4c9c-bb00-a7e95695865f@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
 <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
 <VsNaaQyQoyS5Eg-3BbhfDg9IEe1ARtPKwdfTtU9cHqA=.372b628f-ca92-4c9c-bb00-a7e95695865f@github.com>
Message-ID: <Ge1ZHrAfkodilz05uxfSA0s5wCh_u0gDdHU9t1pTvcI=.e9117921-9d17-42b6-af1e-1d64da350a2f@github.com>

On Tue, 5 Dec 2023 20:07:56 GMT, Phil Race <prr at openjdk.org> wrote:

>> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 71:
>> 
>>> 69:         if (failed) {
>>> 70:             throw new RuntimeException("Test failed but no exception propagated.");
>>> 71:         }
>> 
>> A comment that `pj.print` should not throw exception would suffice, even though it's implied by jtreg any way.
>> 
>> This statement is essentially unreachable if `failed` is set to `true`.
>
> On JDK 17 and earlier you will reach this line with this test as written
> And without that exception, the test would pass when it should fail.

With JDK 17, I still see the exception:


Exception in thread "main" java.awt.print.PrinterException
	at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:393)
	at PrinterDevice.main(PrinterDevice.java:68)
Caused by: java.lang.NullPointerException: Cannot read field "m00" because "Tx" is null
	at java.desktop/java.awt.geom.AffineTransform.<init>(AffineTransform.java:490)
	at java.desktop/sun.print.PrinterGraphicsConfig.getDefaultTransform(PrinterGraphicsConfig.java:105)
	at PrinterDevice.print(PrinterDevice.java:87)


Yet it's fine to ensure no exception is swallowed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416240089

From aivanov at openjdk.org  Tue Dec  5 20:31:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 20:31:38 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v3]
In-Reply-To: <v5I1iz_6FUUJuD9gotm-J_NNbp7dx5BQrZbLGl7QLxk=.0121dad7-df38-4c16-9fc2-9b96e5a4fe64@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <v5I1iz_6FUUJuD9gotm-J_NNbp7dx5BQrZbLGl7QLxk=.0121dad7-df38-4c16-9fc2-9b96e5a4fe64@github.com>
Message-ID: <tWlR70x7A12SLVtSkhwpLWT0RcLRNQeTcEONMnXsbnU=.9b2678c9-8d2b-40a9-99ae-85318c533664@github.com>

On Tue, 5 Dec 2023 20:13:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
>> a printer would give you null for the defaultTransform.
>> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
>> We have a test that would have caught it except that until recently the macOS printing implementation
>> was swallowing exceptions it should not.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320443

Marked as reviewed by aivanov (Reviewer).

test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 109:

> 107:         GraphicsDevice gd = gConfig.getDevice();
> 108:         System.out.println("Printer Device ID = " + gd.getIDstring());
> 109:         if (!(gd.getType() == GraphicsDevice.TYPE_PRINTER)) {

Suggestion:

        if (gd.getType() != GraphicsDevice.TYPE_PRINTER) {

It looks cleaner this way. I missed it when I went over the code the first time.

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

PR Review: https://git.openjdk.org/jdk/pull/16773#pullrequestreview-1766050543
PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416242507

From prr at openjdk.org  Tue Dec  5 20:38:46 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 20:38:46 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v4]
In-Reply-To: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
Message-ID: <grsQeCSi_twr4ipjKW2nsC616gQ8J8gfKh-t51KS7As=.2f569d2c-76e7-4e8e-b0f0-90f5fd27e5b0@github.com>

> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
> a printer would give you null for the defaultTransform.
> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
> We have a test that would have caught it except that until recently the macOS printing implementation
> was swallowing exceptions it should not.

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

  8320443

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16773/files
  - new: https://git.openjdk.org/jdk/pull/16773/files/5a463312..c3830b2f

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

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

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

From azvegint at openjdk.org  Tue Dec  5 20:38:49 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Tue, 5 Dec 2023 20:38:49 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v3]
In-Reply-To: <v5I1iz_6FUUJuD9gotm-J_NNbp7dx5BQrZbLGl7QLxk=.0121dad7-df38-4c16-9fc2-9b96e5a4fe64@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <v5I1iz_6FUUJuD9gotm-J_NNbp7dx5BQrZbLGl7QLxk=.0121dad7-df38-4c16-9fc2-9b96e5a4fe64@github.com>
Message-ID: <2JuMsEJ5FhIQ8eTewIU238Fg1vmKlK2sEiK7Gd5Qr3o=.b986a60a-dc17-4175-860c-11a0db7254cc@github.com>

On Tue, 5 Dec 2023 20:13:50 GMT, Phil Race <prr at openjdk.org> wrote:

>> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
>> a printer would give you null for the defaultTransform.
>> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
>> We have a test that would have caught it except that until recently the macOS printing implementation
>> was swallowing exceptions it should not.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320443

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16773#pullrequestreview-1766056466

From prr at openjdk.org  Tue Dec  5 20:38:49 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 20:38:49 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <Ge1ZHrAfkodilz05uxfSA0s5wCh_u0gDdHU9t1pTvcI=.e9117921-9d17-42b6-af1e-1d64da350a2f@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
 <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
 <VsNaaQyQoyS5Eg-3BbhfDg9IEe1ARtPKwdfTtU9cHqA=.372b628f-ca92-4c9c-bb00-a7e95695865f@github.com>
 <Ge1ZHrAfkodilz05uxfSA0s5wCh_u0gDdHU9t1pTvcI=.e9117921-9d17-42b6-af1e-1d64da350a2f@github.com>
Message-ID: <sBRkBd0MyrbkJ8IjpcQSUVGIe6zRa49YN3B88SSkvLE=.e800e9ac-92f3-4541-a822-7c41fd5edb0c@github.com>

On Tue, 5 Dec 2023 20:25:46 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> On JDK 17 and earlier you will reach this line with this test as written
>> And without that exception, the test would pass when it should fail.
>
> With JDK 17, I still see the exception:
> 
> 
> Exception in thread "main" java.awt.print.PrinterException
> 	at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:393)
> 	at PrinterDevice.main(PrinterDevice.java:68)
> Caused by: java.lang.NullPointerException: Cannot read field "m00" because "Tx" is null
> 	at java.desktop/java.awt.geom.AffineTransform.<init>(AffineTransform.java:490)
> 	at java.desktop/sun.print.PrinterGraphicsConfig.getDefaultTransform(PrinterGraphicsConfig.java:105)
> 	at PrinterDevice.print(PrinterDevice.java:87)
> 
> 
> Yet it's fine to ensure no exception is swallowed.

That exception you are seeing is from the printStackTrace()
If you were to comment out these lines as shown below
@@ -90,9 +90,9 @@ public int print(Graphics g, PageFormat pf, int pageIndex) {
             AffineTransform gt = g2.getTransform();
             System.out.println("Graphics2D transform = " + gt);
         } catch (Exception e) {
-            failed = true;
-            System.err.println("Unexpected exception getting transform.");
-            e.printStackTrace();
+            //failed = true;
+            //System.err.println("Unexpected exception getting transform.");
+            //e.printStackTrace();
             throw e;

then the test would pass on JDK 17

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416246478

From prr at openjdk.org  Tue Dec  5 20:38:52 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 5 Dec 2023 20:38:52 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v3]
In-Reply-To: <tWlR70x7A12SLVtSkhwpLWT0RcLRNQeTcEONMnXsbnU=.9b2678c9-8d2b-40a9-99ae-85318c533664@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <v5I1iz_6FUUJuD9gotm-J_NNbp7dx5BQrZbLGl7QLxk=.0121dad7-df38-4c16-9fc2-9b96e5a4fe64@github.com>
 <tWlR70x7A12SLVtSkhwpLWT0RcLRNQeTcEONMnXsbnU=.9b2678c9-8d2b-40a9-99ae-85318c533664@github.com>
Message-ID: <W4B5wijwNFlGn8sUvlDByTbEtxDQUSZgvH3I-9aTiFM=.be30ba8b-125f-4e87-b1bc-9d7f3600b555@github.com>

On Tue, 5 Dec 2023 20:28:28 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8320443
>
> test/jdk/java/awt/print/PrinterJob/PrinterDevice.java line 109:
> 
>> 107:         GraphicsDevice gd = gConfig.getDevice();
>> 108:         System.out.println("Printer Device ID = " + gd.getIDstring());
>> 109:         if (!(gd.getType() == GraphicsDevice.TYPE_PRINTER)) {
> 
> Suggestion:
> 
>         if (gd.getType() != GraphicsDevice.TYPE_PRINTER) {
> 
> It looks cleaner this way. I missed it when I went over the code the first time.

yes that would be cleaner. updated

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416248417

From aivanov at openjdk.org  Tue Dec  5 20:44:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 20:44:35 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v4]
In-Reply-To: <grsQeCSi_twr4ipjKW2nsC616gQ8J8gfKh-t51KS7As=.2f569d2c-76e7-4e8e-b0f0-90f5fd27e5b0@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <grsQeCSi_twr4ipjKW2nsC616gQ8J8gfKh-t51KS7As=.2f569d2c-76e7-4e8e-b0f0-90f5fd27e5b0@github.com>
Message-ID: <UNJwK2onqhoB_Pmv5e0NkSqNwz8Y9u9LXlqtGrQNGOc=.77e4ab52-dc0e-40f8-9b46-b0298b0e19f6@github.com>

On Tue, 5 Dec 2023 20:38:46 GMT, Phil Race <prr at openjdk.org> wrote:

>> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
>> a printer would give you null for the defaultTransform.
>> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
>> We have a test that would have caught it except that until recently the macOS printing implementation
>> was swallowing exceptions it should not.
>
> Phil Race has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320443

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16773#pullrequestreview-1766070967

From aivanov at openjdk.org  Tue Dec  5 20:44:37 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 5 Dec 2023 20:44:37 GMT
Subject: RFR: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS [v2]
In-Reply-To: <sBRkBd0MyrbkJ8IjpcQSUVGIe6zRa49YN3B88SSkvLE=.e800e9ac-92f3-4541-a822-7c41fd5edb0c@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
 <qEA5M97AMz4pifICbREM8jnIkDB65xpJEdvEFiD2vMc=.71455083-163d-4c8f-8a9c-60464d7c795e@github.com>
 <IAdkK6NW_QM-1Apv_rSyvYYOMftvzb9SkvQhq4HA-fs=.d4afea1e-9f97-47e0-9fd0-0a7beb534921@github.com>
 <VsNaaQyQoyS5Eg-3BbhfDg9IEe1ARtPKwdfTtU9cHqA=.372b628f-ca92-4c9c-bb00-a7e95695865f@github.com>
 <Ge1ZHrAfkodilz05uxfSA0s5wCh_u0gDdHU9t1pTvcI=.e9117921-9d17-42b6-af1e-1d64da350a2f@github.com>
 <sBRkBd0MyrbkJ8IjpcQSUVGIe6zRa49YN3B88SSkvLE=.e800e9ac-92f3-4541-a822-7c41fd5edb0c@github.com>
Message-ID: <hWaPwmQBOQIxRZmgPXlXFpH9sFvqJBjx04F8cjpWmds=.28e293a9-b857-489b-82f8-6f33bcb063d8@github.com>

On Tue, 5 Dec 2023 20:32:49 GMT, Phil Race <prr at openjdk.org> wrote:

>> With JDK 17, I still see the exception:
>> 
>> 
>> Exception in thread "main" java.awt.print.PrinterException
>> 	at java.desktop/sun.lwawt.macosx.CPrinterJob.print(CPrinterJob.java:393)
>> 	at PrinterDevice.main(PrinterDevice.java:68)
>> Caused by: java.lang.NullPointerException: Cannot read field "m00" because "Tx" is null
>> 	at java.desktop/java.awt.geom.AffineTransform.<init>(AffineTransform.java:490)
>> 	at java.desktop/sun.print.PrinterGraphicsConfig.getDefaultTransform(PrinterGraphicsConfig.java:105)
>> 	at PrinterDevice.print(PrinterDevice.java:87)
>> 
>> 
>> Yet it's fine to ensure no exception is swallowed.
>
> That exception you are seeing is from the printStackTrace()
> If you were to comment out these lines as shown below
> @@ -90,9 +90,9 @@ public int print(Graphics g, PageFormat pf, int pageIndex) {
>              AffineTransform gt = g2.getTransform();
>              System.out.println("Graphics2D transform = " + gt);
>          } catch (Exception e) {
> -            failed = true;
> -            System.err.println("Unexpected exception getting transform.");
> -            e.printStackTrace();
> +            //failed = true;
> +            //System.err.println("Unexpected exception getting transform.");
> +            //e.printStackTrace();
>              throw e;
> 
> then the test would pass on JDK 17

Nope, I checked that it's the real exception. Yet I used a recent version of JDK 17 where [JDK-8262731](https://bugs.openjdk.org/browse/JDK-8262731) was fixed, it's present in 17.0.1.

Indeed, the test passes with GA version of JDK 17 without the `failed` field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16773#discussion_r1416254033

From duke at openjdk.org  Tue Dec  5 20:48:36 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Tue, 5 Dec 2023 20:48:36 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling
In-Reply-To: <xOWfXpxBpwBiSCdgXzK3rPy7YFeH0qc5ccd_jg6u-8M=.3c9f4727-1e0f-4a38-b930-caf1f7cc93ab@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <xOWfXpxBpwBiSCdgXzK3rPy7YFeH0qc5ccd_jg6u-8M=.3c9f4727-1e0f-4a38-b930-caf1f7cc93ab@github.com>
Message-ID: <xsvZCclFaPV3wSZjziLGi_VBxIhYFUOuYYgCYcEIy7A=.f31c8c3d-02e1-4cb4-8088-38d64125e3f7@github.com>

On Tue, 5 Dec 2023 20:22:32 GMT, Phil Race <prr at openjdk.org> wrote:

>> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
>> 
>> The real major change here however is the throw of the RuntimeException which can propagate to public 
>> 
>> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
>> 
>> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
>> 
>> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
>> 
>> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.
>
> src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 223:
> 
>> 221:         } else if (retVal == ERROR) {
>> 222:             throw new RuntimeException(
>> 223:                 "Screen capture has failed due to desktop environment error");
> 
> Please remove this

@prrace have you read my description of this PR? If so, and based on that, what can you propose to address the problem described?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1416258184

From serb at openjdk.org  Wed Dec  6 00:22:41 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 6 Dec 2023 00:22:41 GMT
Subject: Integrated: 8321325: Remove unused Java_java_awt_MenuComponent_initIDs
 function
In-Reply-To: <vrzPyuK7tzjy0Er0zov8GDgAgDdpVEXt6ijVmHwtqGw=.a62bd246-3af6-4de1-8923-cdd2263d8319@github.com>
References: <vrzPyuK7tzjy0Er0zov8GDgAgDdpVEXt6ijVmHwtqGw=.a62bd246-3af6-4de1-8923-cdd2263d8319@github.com>
Message-ID: <NgIuap_htXOqkvNX-7ljt0AsD_jcFbsZ5pxgu770yF8=.95684d0a-b567-4a65-af1d-21764b14a2fc@github.com>

On Tue, 5 Dec 2023 08:30:44 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The Java_java_awt_MenuComponent_initIDs function is empty on Windows and macOS, on linux it has some code but it is unused.
> 
> This issue is similar to https://bugs.openjdk.org/browse/JDK-8318091

This pull request has now been integrated.

Changeset: 3cd65ce2
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3cd65ce2a492726cf1c30bf0c4bfaf0980323fab
Stats:     81 lines in 6 files changed: 0 ins; 80 del; 1 mod

8321325: Remove unused Java_java_awt_MenuComponent_initIDs function

Reviewed-by: prr, aivanov

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

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

From philip.race at oracle.com  Wed Dec  6 02:25:24 2023
From: philip.race at oracle.com (Philip Race)
Date: Tue, 5 Dec 2023 18:25:24 -0800
Subject: proposing the depreciation of java.beans.beancontext.*
In-Reply-To: <6679fe8c-1dde-b667-2274-918fe7ac4a60@oracle.com>
References: <c63c64e5-138e-7047-5701-f55a65835400@oracle.com>
 <b05fad9c-d3ca-3f31-375a-fadde9561472@oracle.com>
 <6679fe8c-1dde-b667-2274-918fe7ac4a60@oracle.com>
Message-ID: <417d55dd-920b-4983-b6ac-dec1afb1096a@oracle.com>

Larry,

I submitted https://bugs.openjdk.org/browse/JDK-8321428.
I've assigned it to you, on the assumption you are interested.
Obviously no particular urgency around this.

-phil.

On 9/21/23 4:48 PM, Laurence Cable wrote:
> Hi Phillip, inline ...
>
> On 9/21/23 4:16 PM, Philip Race wrote:
>> Hi Larry,
>>
>> Deprecation happens either because there is a preferred replacement 
>> or because something
>> is dangerous or obsolete. This is a slightly blurred case, since it 
>> seems to be obsoleted by
>> a preferred pattern that doesn't involve a JDK replacement API.
>>
>> I guess the first question I have is do you mean just "deprecate" and 
>> provide pointers, or
>> do you mean "deprecate for removal". The latter needs more 
>> consideration, like
>
> I mean the latter - eventual removal, return some bytes for better 
> usage since its my opinion beancontext is long past being obsolete... 
> its pretty much only of historical/archeological interest at this 
> point in time! :)
>
>>
>> (1) Is any actively supported software still using this ?
>
> I intend to perform some corpus searches to determine this (to the 
> degree possible)
>
>> (2) How hard would it be for them to migrate to something else ? And 
>> how reasonable is it to expect them to do so?
>
> I would anticipate that any code written after the onset of Spring, 
> Guice etc would have already abandoned beancontext!
>
>> (3) What's the ripple effect in the JDK ? Does it impact the 
>> java.beans package too in some ways ?
>
> AFIAK/recall the beancontext and beans pkgs are effectively 
> independent of each other ... at least in the dependency 'direction' 
> of beans -> beancontext.
>
> I do not recall any other packages (e.g awt) using it, but a search of 
> the JDK will confirm this.
>
> beancontext did not really gain any significant adoption that I was 
> aware of, once DI/IoT became the de facto model for component/bean 
> assembly with Spring and that percolated down into SE from EE,
> along with OSGi (which also had overlap in the area of 
> service/interface brokerage)
>
> Rgds
>
> - Larry
>
>>
>> -phil.
>>
>>
>> On 9/20/23 5:18 PM, Laurence Cable wrote:
>>> The BeanContext.* package was added (by me) quite early in the 
>>> lifetime of java beans (1.2); based loosely on some of the concepts 
>>> of the opendoc component framework,
>>> it was intended to provide a "container" for JavaBeans components to 
>>> collaborate with each other by exposing both their presence (within 
>>> a context)
>>> and to provide/consume 'services' expressed as interfaces.
>>>
>>> (we even demoed this functionality in the "beanbox" for those that 
>>> recall that)
>>>
>>> This package pre-dated the invention/discovery of Inversion of 
>>> Control and (annotation based) Dependency Injection by a good number 
>>> of years; and as those latter design patterns
>>> and their implementations became popular, Bean Context did not 
>>> evolve, and I would argue, became rapidly irrelevant if not actually 
>>> an anti-pattern!
>>>
>>> Now some 25 yrs later, it is probably beyond definition as an 
>>> anachronism and long overdue to be depreciated from the JDK.
>>>
>>> Therefore I would like to propose doing so, and open the discussion 
>>> regarding this here.
>>>
>>> Regards
>>>
>>> - Larry
>>
>


From azvegint at openjdk.org  Wed Dec  6 04:57:33 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 6 Dec 2023 04:57:33 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling
In-Reply-To: <xsvZCclFaPV3wSZjziLGi_VBxIhYFUOuYYgCYcEIy7A=.f31c8c3d-02e1-4cb4-8088-38d64125e3f7@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <xOWfXpxBpwBiSCdgXzK3rPy7YFeH0qc5ccd_jg6u-8M=.3c9f4727-1e0f-4a38-b930-caf1f7cc93ab@github.com>
 <xsvZCclFaPV3wSZjziLGi_VBxIhYFUOuYYgCYcEIy7A=.f31c8c3d-02e1-4cb4-8088-38d64125e3f7@github.com>
Message-ID: <naSLKPh3wQ3XFAH6Ax1wGMOTQ4z3nK2mB5DGzrzJl5o=.cec066fa-7c34-4df2-9235-79316b970efb@github.com>

On Tue, 5 Dec 2023 20:45:58 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> src/java.desktop/unix/classes/sun/awt/screencast/ScreencastHelper.java line 223:
>> 
>>> 221:         } else if (retVal == ERROR) {
>>> 222:             throw new RuntimeException(
>>> 223:                 "Screen capture has failed due to desktop environment error");
>> 
>> Please remove this
>
> @prrace have you read my description of this PR? If so, and based on that, what can you propose to address the problem described?

Such change requires a [CSR](https://wiki.openjdk.org/display/csr) .
If we want to get this fix into JDK 22, we don't have time for CSR, since JDK 22 will be forked this Thursday.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1416655172

From azvegint at openjdk.org  Wed Dec  6 04:57:37 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 6 Dec 2023 04:57:37 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling
In-Reply-To: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
Message-ID: <esksTyK-9IP0EuYUAATEw6nYsTtWyIGYoiP3sCd2JIY=.51981b36-de2c-49bd-bb1f-a43102558d57@github.com>

On Tue, 5 Dec 2023 16:48:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
> 
> The real major change here however is the throw of the RuntimeException which can propagate to public 
> 
> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
> 
> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
> 
> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
> 
> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 26:

> 24:  */
> 25: 
> 26: #include "debug_util.h"

Looks like this header is not used.

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 891:

> 889:         if (hasPipewireFailed) {
> 890:             doCleanup();
> 891:             fp_pw_thread_loop_unlock(pw.loop);

All other `doCleanup` calls are made without the lock, let's be consistent.

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 959:

> 957:         token, &requestedArea, affectedScreenBounds, affectedBoundsLength);
> 958: 
> 959:     if (attemptResult) {

I don't think we should make another attempt if there is no saved token and the user rejected the first screen capture request:

Suggestion:

    if (attemptResult) {
        if (attemptResult == RESULT_DENIED) {
            releaseToken(env, jtoken, token);
            return RESULT_DENIED;
        }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1416611308
PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1416612933
PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1416618136

From tr at openjdk.org  Wed Dec  6 05:20:40 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 6 Dec 2023 05:20:40 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v7]
In-Reply-To: <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
Message-ID: <TZxNSVz0mKn7Rh5kInm7y_eB6eTU91IAXUMPu2SQn14=.e6fe22a6-fa56-40ac-9322-dd6e0a682a8f@github.com>

On Tue, 5 Dec 2023 19:35:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 206:

> 204:     }
> 205: 
> 206:     private static void checkResult(UIManager.LookAndFeelInfo laf) throws Exception {

Instead of passing the laf through all the methods, can't we create and use a class variable?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1416677619

From duke at openjdk.org  Wed Dec  6 09:08:55 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Wed, 6 Dec 2023 09:08:55 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling [v2]
In-Reply-To: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
Message-ID: <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>

> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
> 
> The real major change here however is the throw of the RuntimeException which can propagate to public 
> 
> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
> 
> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
> 
> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
> 
> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.

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

  8321176: remove RuntimeException and address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16978/files
  - new: https://git.openjdk.org/jdk/pull/16978/files/8f79cac7..a473b9d2

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

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

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

From duke at openjdk.org  Wed Dec  6 09:27:40 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Wed, 6 Dec 2023 09:27:40 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling [v2]
In-Reply-To: <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
Message-ID: <pUReTGS2_i8PZPatEOFkpdvkwg0Ont5dxzAMUafaAZE=.0ffc0942-035b-48f9-ade8-16d4e6ab7d00@github.com>

On Wed, 6 Dec 2023 09:08:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
>> 
>> The real major change here however is the throw of the RuntimeException which can propagate to public 
>> 
>> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
>> 
>> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
>> 
>> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
>> 
>> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.
>
> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8321176: remove RuntimeException and address review comments

@azvegint thanks for review! yeah the CSR looks like a long story so lets skip it in this patch however i feel that the problem has to be addressed somehow going forward as i dont think the current behavior is acceptable. there could be cases where it can cause real problems eg imagine some sort of medical imaging app where it could fail intermittently and report wrong pixel colors etc. can you please file a bug based on my description above ?

and also something i thought i should mention wrt doCleanup() function. it might be a good idea to protect it with a mutex or something. it does look safe ATM but i haven't looked at related libpipewire internals to assert that with full certainty. there perhaps could be a situation where doCleanup() is called internally but also from java cleanup thread (the one that sleeps for 2 seconds) and if they interleave/race it might cause unexpected behavior or crash in libpipewire as its rather sensible in terms of teardown sequence (i've seen its crashing due to that in my testing and thats why i have reshuffled some related calls in this patch). anyways, this is something to look into and check.

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

PR Comment: https://git.openjdk.org/jdk/pull/16978#issuecomment-1842498910

From abhiscxk at openjdk.org  Wed Dec  6 10:58:39 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Dec 2023 10:58:39 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v7]
In-Reply-To: <TZxNSVz0mKn7Rh5kInm7y_eB6eTU91IAXUMPu2SQn14=.e6fe22a6-fa56-40ac-9322-dd6e0a682a8f@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
 <TZxNSVz0mKn7Rh5kInm7y_eB6eTU91IAXUMPu2SQn14=.e6fe22a6-fa56-40ac-9322-dd6e0a682a8f@github.com>
Message-ID: <9OmLTelGtZ6hg8A-39tLjCUBLa9A257RUnj00vrEpvg=.cd57700a-44fb-45c8-b353-89529ef72a30@github.com>

On Wed, 6 Dec 2023 05:17:34 GMT, Tejesh R <tr at openjdk.org> wrote:

> Instead of passing the laf through all the methods, can't we create and use a class variable?

Can be done but can't see any functional improvements. This seems ok to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1417099339

From psadhukhan at openjdk.org  Wed Dec  6 11:47:03 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Dec 2023 11:47:03 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking [v3]
In-Reply-To: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
Message-ID: <h-QjB3VbNryANMLOUQBwxcfvHiAuDQaTg3DSNJiZ1lM=.cd2f88ba-f529-41a6-8856-ba78aa4e4489@github.com>

> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

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

  Set loadedImage after image load

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16917/files
  - new: https://git.openjdk.org/jdk/pull/16917/files/af2b9303..503cc2cd

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

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

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

From psadhukhan at openjdk.org  Wed Dec  6 11:47:06 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 6 Dec 2023 11:47:06 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking [v2]
In-Reply-To: <xli7bkozj-wgTSKTAdA7Whc6n6EiE_lwDu0ZVk9KxaU=.646301f4-8ea8-48bd-abe0-db64e74e935c@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <xli7bkozj-wgTSKTAdA7Whc6n6EiE_lwDu0ZVk9KxaU=.646301f4-8ea8-48bd-abe0-db64e74e935c@github.com>
Message-ID: <9qWL__h0tWj2vE2ej6nSAbJYledHmyOMaDUhs9ObVD4=.6448ae94-0daa-4ea2-969d-82e534e7b584@github.com>

On Tue, 5 Dec 2023 07:59:19 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use image field for DCL

> > But it can be a bug in the code that it never gave a chance second time..I think it should get a chance to reload the URL again in case it is invalid the 1st time so I guess the change should be the one where if url is invalid, `loadedImage ` should not be set and it will need a relook at the url (to be set by user)
> 
> My point is it must re-load the image **whenever base is changed**, as @mrserb pointed out.
> 
> If you want to implement this feature, submit a new bug ? it is out of scope for this issue. Better yet, just submit the new bug to document the discovered problem.
> 
> Re-loading the image if and only if the `url` is `null` is inconsistent. I strongly believe the image is to be re-loaded either _always_ or _never_ at all rather than sometimes.
> 
> Currently, it's in _never_ mode. I am for preserving the current behaviour rather than adding a half-baked solution.

OK. I have had my doubts but I agree to keep it as similar to code we have it now..Modified the PR..

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

PR Comment: https://git.openjdk.org/jdk/pull/16917#issuecomment-1842710289

From tr at openjdk.org  Wed Dec  6 13:21:41 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 6 Dec 2023 13:21:41 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v7]
In-Reply-To: <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
Message-ID: <mDKTQ5J81yLaC-zaWoQPvmvlO0NdtwVgNor2DFtlw-Y=.8be16f50-b092-49f1-a9b8-268fe7e64418@github.com>

On Tue, 5 Dec 2023 19:35:50 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
>> Tested the current change on the machine it failed for multiple times, no failure observed.
>> CI link attached in JBS.
>
> Abhishek Kumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year update

Marked as reviewed by tr (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16674#pullrequestreview-1767534029

From tr at openjdk.org  Wed Dec  6 13:21:42 2023
From: tr at openjdk.org (Tejesh R)
Date: Wed, 6 Dec 2023 13:21:42 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v7]
In-Reply-To: <9OmLTelGtZ6hg8A-39tLjCUBLa9A257RUnj00vrEpvg=.cd57700a-44fb-45c8-b353-89529ef72a30@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
 <TZxNSVz0mKn7Rh5kInm7y_eB6eTU91IAXUMPu2SQn14=.e6fe22a6-fa56-40ac-9322-dd6e0a682a8f@github.com>
 <9OmLTelGtZ6hg8A-39tLjCUBLa9A257RUnj00vrEpvg=.cd57700a-44fb-45c8-b353-89529ef72a30@github.com>
Message-ID: <hHbN8pAtghRTlNkAY2uu2wKW4g9DOgBN3brCgZpBBjA=.683fa33f-8dd1-4679-94dd-8246c1159e9d@github.com>

On Wed, 6 Dec 2023 10:55:33 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

>> test/jdk/com/sun/java/swing/plaf/gtk/TestFileChooserSingleDirectorySelection.java line 206:
>> 
>>> 204:     }
>>> 205: 
>>> 206:     private static void checkResult(UIManager.LookAndFeelInfo laf) throws Exception {
>> 
>> Instead of passing the laf through all the methods, can't we create and use a class variable?
>
>> Instead of passing the laf through all the methods, can't we create and use a class variable?
> 
> Can be done but can't see any functional improvements. This seems ok to me.

Yeah, those are to reduce redundancy in code, not functional...... Otherwise the fix looks fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1417286814

From aivanov at openjdk.org  Wed Dec  6 14:32:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Dec 2023 14:32:38 GMT
Subject: RFR: 8319938: TestFileChooserSingleDirectorySelection.java fails
 with "getSelectedFiles returned empty array" [v7]
In-Reply-To: <hHbN8pAtghRTlNkAY2uu2wKW4g9DOgBN3brCgZpBBjA=.683fa33f-8dd1-4679-94dd-8246c1159e9d@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
 <gxw_4muJ740q-Xl3QbGVNG8TtRf7NOGypOQgyahq2aY=.7eec52bd-7c8d-4c77-8625-88068163bf2a@github.com>
 <TZxNSVz0mKn7Rh5kInm7y_eB6eTU91IAXUMPu2SQn14=.e6fe22a6-fa56-40ac-9322-dd6e0a682a8f@github.com>
 <9OmLTelGtZ6hg8A-39tLjCUBLa9A257RUnj00vrEpvg=.cd57700a-44fb-45c8-b353-89529ef72a30@github.com>
 <hHbN8pAtghRTlNkAY2uu2wKW4g9DOgBN3brCgZpBBjA=.683fa33f-8dd1-4679-94dd-8246c1159e9d@github.com>
Message-ID: <tI6tBmC8PrRjoIqK5g7RDlSnmyWdgU-crZXdAU6o8NQ=.d38b65d3-54a0-468d-8cd9-72a602d9ede3@github.com>

On Wed, 6 Dec 2023 13:18:53 GMT, Tejesh R <tr at openjdk.org> wrote:

>>> Instead of passing the laf through all the methods, can't we create and use a class variable?
>> 
>> Can be done but can't see any functional improvements. This seems ok to me.
>
> Yeah, those are to reduce redundancy in code, not functional...... Otherwise the fix looks fine.

It's not redundancy: passing the `laf` explicitly makes the data flow clearer, even though `laf` isn't directly used.

I agree that making `laf` a class field doesn't provide much benefit.

In a way, it could be removed completely, however, reporting the L&F at which the test case failed gives more details, you don't need to look at the test log to find the L&F.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16674#discussion_r1417416141

From vdyakov at openjdk.org  Wed Dec  6 16:37:34 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Wed, 6 Dec 2023 16:37:34 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <rI0PmZ_zxji1m461gJ7Y1gRBKlgEGghU6Gh7dt2deNk=.c4cd89e4-3e53-42f8-848f-42f095444958@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

@honkar-jdk @alisenchung @aivanov-jdk please review

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

PR Comment: https://git.openjdk.org/jdk/pull/16960#issuecomment-1843254751

From abhiscxk at openjdk.org  Wed Dec  6 16:44:52 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Wed, 6 Dec 2023 16:44:52 GMT
Subject: Integrated: 8319938: TestFileChooserSingleDirectorySelection.java
 fails with "getSelectedFiles returned empty array"
In-Reply-To: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
References: <phDTeaNtXcRfFuYKrA2squfsX4OYQGiwfA_8QLshYec=.72c445eb-1659-43b2-a748-706b5f0c2942@github.com>
Message-ID: <BXu1ZIEd_Yy8ym-d_x1T0iz6LF7O5WxmMd-ZkNPKfUA=.56215958-b680-42f5-b547-ba91b0db02af@github.com>

On Wed, 15 Nov 2023 09:50:19 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> The test fails for JFileChooser selection mode set to `DIRECTORIES_ONLY`. For `DIRECTORIES_ONLY `mode, there may not be any directories in home directory and due to that test failed. Added the code to create temporary directories and files for the test.
> Tested the current change on the machine it failed for multiple times, no failure observed.
> CI link attached in JBS.

This pull request has now been integrated.

Changeset: 4ef24e25
Author:    Abhishek Kumar <abhiscxk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ef24e2596340c5375f2ab07883c26a6458efe0e
Stats:     148 lines in 1 file changed: 58 ins; 53 del; 37 mod

8319938: TestFileChooserSingleDirectorySelection.java fails with "getSelectedFiles returned empty array"

Reviewed-by: aivanov, tr

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

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

From prr at openjdk.org  Wed Dec  6 16:48:40 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Dec 2023 16:48:40 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <up7U-jEe1aT5PWdj1jBh8gDGTN769hcyyEfNqF_rU14=.d23d5c43-5452-4ca5-80d0-9081b4131704@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

Marked as reviewed by prr (Reviewer).

src/java.desktop/unix/classes/sun/awt/X11/XWM.java line 1376:

> 1374:                   break;
> 1375:               case MOTIF_WM:
> 1376:               case OPENLOOK_WM:

Out of scope for this fix but in a future fix I think we can get rid of at least
(1) LG3D
(2) OPENLOOK
and very probably
(3) MOTIF
and perhaps also
(4) CDE

They are all obsolete.

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

PR Review: https://git.openjdk.org/jdk/pull/16960#pullrequestreview-1768082781
PR Review Comment: https://git.openjdk.org/jdk/pull/16960#discussion_r1417641109

From prr at openjdk.org  Wed Dec  6 16:48:43 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Dec 2023 16:48:43 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <3m7BOjGOzodnLWdvI_uFU_HJF8UEBuRxAWyIGuSC1Mk=.79e26925-f1d4-4129-92d6-38687cc4d1e1@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
 <3m7BOjGOzodnLWdvI_uFU_HJF8UEBuRxAWyIGuSC1Mk=.79e26925-f1d4-4129-92d6-38687cc4d1e1@github.com>
Message-ID: <AFboGz1C2LfAFeUk5whVtsprJQDDNR4qmD8eQwm9Sog=.f659a403-3d8a-48dc-9841-8f32c7c71c1f@github.com>

On Mon, 4 Dec 2023 23:27:23 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The root of this issue is the incorrect calculation of window decoration insets.
>> 
>> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
>> 
>> This changed starting with Ubuntu 23.04:
>> Now we can get several such notifications with zero window insets, and only then the correct value.
>> 
>> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
>> 
>> The solution is to change these insets on the fly, for now only for Mutter window manager. 
>> The guessInsets for it have also been updated.
>> 
>> 
>> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
>> 
>> Testing looks good.
>
> test/jdk/ProblemList.txt line 461:
> 
>> 459: java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeForModalDialogTest/ConsumeForModalDialogTest.java 8302787 windows-all
>> 460: java/awt/KeyboardFocusmanager/TypeAhead/MenuItemActivatedTest/MenuItemActivatedTest.java 8302787 windows-all
>> 461: java/awt/KeyboardFocusmanager/ConsumeNextMnemonicKeyTypedTest/ConsumeNextMnemonicKeyTypedTest.java 8321303 linux-all
> 
> This intermittent issue is more reproducible after the fix, however it was there before. 
> I am able to reproduce it with various JDK 11, 17, 19, 21, 22 (more info and a reproducer is available [here](https://bugs.openjdk.org/browse/JDK-8321303))

This test has been problematic in the past.
Eg https://bugs.openjdk.org/browse/JDK-8283896

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16960#discussion_r1417650935

From vdyakov at openjdk.org  Wed Dec  6 17:26:35 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Wed, 6 Dec 2023 17:26:35 GMT
Subject: RFR: 8320057: [macos14]
 javax/swing/JToolTip/4846413/bug4846413.java: Tooltip has not been found!
In-Reply-To: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
References: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
Message-ID: <HZEYYJjWqPPT7rrbAjllO9ilI2YiaP_lSAKp96F7sOA=.d212374b-e450-4d54-a94b-415e21b23cd8@github.com>

On Wed, 22 Nov 2023 08:46:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test failing on macos14 citing "ToolTip not found"...Investigation shows that the mouse is not moved when invoked 1st time to desired location on screen causing tooltip to not show...However, subsequent runs of the same test without any change causes it to pass every time.
> Workaround is proposed to check if running on 14.x, then invoke a dummy mouse movement to same location which causes the test to pass for several iterations in macos14 environment.

@prsadhuk @honkar-jdk @prrace is it ongoing next 24 hours?

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

PR Comment: https://git.openjdk.org/jdk/pull/16776#issuecomment-1843337196

From honkar at openjdk.org  Wed Dec  6 17:49:33 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 6 Dec 2023 17:49:33 GMT
Subject: RFR: 8320057: [macos14]
 javax/swing/JToolTip/4846413/bug4846413.java: Tooltip has not been found!
In-Reply-To: <HZEYYJjWqPPT7rrbAjllO9ilI2YiaP_lSAKp96F7sOA=.d212374b-e450-4d54-a94b-415e21b23cd8@github.com>
References: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
 <HZEYYJjWqPPT7rrbAjllO9ilI2YiaP_lSAKp96F7sOA=.d212374b-e450-4d54-a94b-415e21b23cd8@github.com>
Message-ID: <_rqHyofKS-GyclpYRGU54pfDjgtW3op0hs3Yh96jW84=.a4bf5b60-dc44-48e3-95ea-4fe8ef1f0d11@github.com>

On Wed, 6 Dec 2023 17:24:20 GMT, Victor Dyakov <vdyakov at openjdk.org> wrote:

> @prsadhuk @honkar-jdk @prrace is it ongoing next 24 hours?

@victordyakov The test fix consists of macOS version specific fix - adding an extra mouse event. But since we are trying find the root cause behind the issue and it might end up being reported as Apple Bug https://github.com/openjdk/jdk/pull/16776#issuecomment-1823319467, I believe this is not being targeted for tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/16776#issuecomment-1843374124

From azvegint at openjdk.org  Wed Dec  6 18:07:36 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 6 Dec 2023 18:07:36 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure, improve pipewire error handling [v2]
In-Reply-To: <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
Message-ID: <aSRI0JBfQYi-NDq8VfdOD_U6CMojoTtyZQxPoTzWRv0=.f50cb0ae-abea-4814-9606-d369bf12312b@github.com>

On Wed, 6 Dec 2023 09:08:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
>> 
>> The real major change here however is the throw of the RuntimeException which can propagate to public 
>> 
>> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
>> 
>> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
>> 
>> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
>> 
>> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.
>
> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8321176: remove RuntimeException and address review comments

Looks good to me.

> can you please file a bug based on my description above ?

Filed the [JDK-8321475](https://bugs.openjdk.org/browse/JDK-8321475) for this

> and also something i thought i should mention wrt doCleanup() function. it might be a good idea to protect it with a mutex or something. it does look safe ATM but i haven't looked at related libpipewire internals to assert that with full certainty. there perhaps could be a situation where doCleanup() is called internally but also from java cleanup thread (the one that sleeps for 2 seconds) and if they interleave/race it might cause unexpected behavior or crash in libpipewire as its rather sensible in terms of teardown sequence (i've seen its crashing due to that in my testing and thats why i have reshuffled some related calls in this patch). anyways, this is something to look into and check.

Sure, we should revisit it later.

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

Marked as reviewed by azvegint (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16978#pullrequestreview-1768293452

From achung at openjdk.org  Wed Dec  6 18:36:37 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 6 Dec 2023 18:36:37 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <jRFPET8vSTaChixR_DSF3LOwlhi634D_MFyE8uY0pkQ=.6f51adba-08ad-4135-87fb-f81ab14d9145@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

src/java.desktop/unix/classes/sun/awt/X11/XWM.java line 1373:

> 1371:                   break;
> 1372:               case MUTTER_WM:
> 1373:                   res = new Insets(37, 0, 0, 0);

How did you come up with the numbers for these insets?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16960#discussion_r1417817303

From azvegint at openjdk.org  Wed Dec  6 18:54:35 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 6 Dec 2023 18:54:35 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <jRFPET8vSTaChixR_DSF3LOwlhi634D_MFyE8uY0pkQ=.6f51adba-08ad-4135-87fb-f81ab14d9145@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
 <jRFPET8vSTaChixR_DSF3LOwlhi634D_MFyE8uY0pkQ=.6f51adba-08ad-4135-87fb-f81ab14d9145@github.com>
Message-ID: <BGKqcZIiYJbVGg3ybqxS579Sa-YG2fRn0h-EP1P_B0Q=.a4c9e0a2-b1c4-461b-b8b0-c3d4109b2861@github.com>

On Wed, 6 Dec 2023 18:33:56 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> The root of this issue is the incorrect calculation of window decoration insets.
>> 
>> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
>> 
>> This changed starting with Ubuntu 23.04:
>> Now we can get several such notifications with zero window insets, and only then the correct value.
>> 
>> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
>> 
>> The solution is to change these insets on the fly, for now only for Mutter window manager. 
>> The guessInsets for it have also been updated.
>> 
>> 
>> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
>> 
>> Testing looks good.
>
> src/java.desktop/unix/classes/sun/awt/X11/XWM.java line 1373:
> 
>> 1371:                   break;
>> 1372:               case MUTTER_WM:
>> 1373:                   res = new Insets(37, 0, 0, 0);
> 
> How did you come up with the numbers for these insets?

They are obtained from the system, and are a default value for the Gnome shell (which uses Mutter WM).
You can get them with `window.getInsets()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16960#discussion_r1417847020

From duke at openjdk.org  Wed Dec  6 18:58:35 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Wed, 6 Dec 2023 18:58:35 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <aSRI0JBfQYi-NDq8VfdOD_U6CMojoTtyZQxPoTzWRv0=.f50cb0ae-abea-4814-9606-d369bf12312b@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
 <aSRI0JBfQYi-NDq8VfdOD_U6CMojoTtyZQxPoTzWRv0=.f50cb0ae-abea-4814-9606-d369bf12312b@github.com>
Message-ID: <5VosgVvSL-v22IbCHH3EHU2eUwdSMjB0MTBdlYBvqbI=.972a0cb5-070a-437a-86c3-aa33a96a6f4e@github.com>

On Wed, 6 Dec 2023 18:04:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8321176: remove RuntimeException and address review comments
>
> Looks good to me.
> 
>> can you please file a bug based on my description above ?
> 
> Filed the [JDK-8321475](https://bugs.openjdk.org/browse/JDK-8321475) for this
> 
>> and also something i thought i should mention wrt doCleanup() function. it might be a good idea to protect it with a mutex or something. it does look safe ATM but i haven't looked at related libpipewire internals to assert that with full certainty. there perhaps could be a situation where doCleanup() is called internally but also from java cleanup thread (the one that sleeps for 2 seconds) and if they interleave/race it might cause unexpected behavior or crash in libpipewire as its rather sensible in terms of teardown sequence (i've seen its crashing due to that in my testing and thats why i have reshuffled some related calls in this patch). anyways, this is something to look into and check.
> 
> Sure, we should revisit it later.

@azvegint super, thanks again!

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

PR Comment: https://git.openjdk.org/jdk/pull/16978#issuecomment-1843513018

From prr at openjdk.org  Wed Dec  6 19:07:42 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Dec 2023 19:07:42 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <naSLKPh3wQ3XFAH6Ax1wGMOTQ4z3nK2mB5DGzrzJl5o=.cec066fa-7c34-4df2-9235-79316b970efb@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <xOWfXpxBpwBiSCdgXzK3rPy7YFeH0qc5ccd_jg6u-8M=.3c9f4727-1e0f-4a38-b930-caf1f7cc93ab@github.com>
 <xsvZCclFaPV3wSZjziLGi_VBxIhYFUOuYYgCYcEIy7A=.f31c8c3d-02e1-4cb4-8088-38d64125e3f7@github.com>
 <naSLKPh3wQ3XFAH6Ax1wGMOTQ4z3nK2mB5DGzrzJl5o=.cec066fa-7c34-4df2-9235-79316b970efb@github.com>
Message-ID: <Q8E7T0Yx7SG7fau8NPkhep7mLGVJc3YD1Vlj2g7qhZQ=.0bf7b2c5-664b-49c0-978d-67608b1a9cc4@github.com>

On Wed, 6 Dec 2023 04:54:02 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> @prrace have you read my description of this PR? If so, and based on that, what can you propose to address the problem described?
>
> Such change requires a [CSR](https://wiki.openjdk.org/display/csr) .
> If we want to get this fix into JDK 22, we don't have time for CSR, since JDK 22 will be forked this Thursday.

It is beyond that. It is an incompatible change. It will be rejected forever.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1417860270

From prr at openjdk.org  Wed Dec  6 19:23:38 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Dec 2023 19:23:38 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
Message-ID: <3oYrQJQd6ddztw3rvYvPVFko86BVvboscWVOssEsscA=.9ac97daf-9ada-4590-94df-7169533747cb@github.com>

On Wed, 6 Dec 2023 09:08:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
>> 
>> The real major change here however is the throw of the RuntimeException which can propagate to public 
>> 
>> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
>> 
>> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
>> 
>> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
>> 
>> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.
>
> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8321176: remove RuntimeException and address review comments

src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 102:

> 100:             if (screenProps->data->stream) {
> 101:                 fp_pw_thread_loop_lock(pw.loop);
> 102:                 fp_pw_stream_disconnect(screenProps->data->stream);

I had this disconnect inside the lock in an earlier PR 
https://github.com/openjdk/jdk/pull/14428/files?diff=unified&w=0#diff-3ba5df79cdd3da36b21bf29b4e8de462dd61e6a21dfe0816e4d84c18bbfb76b2R92
but then it was moved out of the lock in another PR to fix a bug https://bugs.openjdk.org/browse/JDK-8310334
https://github.com/openjdk/jdk/pull/15250/files#diff-3ba5df79cdd3da36b21bf29b4e8de462dd61e6a21dfe0816e4d84c18bbfb76b2


So how can it be right to put it back inside the lock ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1417874272

From duke at openjdk.org  Wed Dec  6 19:30:36 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Wed, 6 Dec 2023 19:30:36 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <Q8E7T0Yx7SG7fau8NPkhep7mLGVJc3YD1Vlj2g7qhZQ=.0bf7b2c5-664b-49c0-978d-67608b1a9cc4@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <xOWfXpxBpwBiSCdgXzK3rPy7YFeH0qc5ccd_jg6u-8M=.3c9f4727-1e0f-4a38-b930-caf1f7cc93ab@github.com>
 <xsvZCclFaPV3wSZjziLGi_VBxIhYFUOuYYgCYcEIy7A=.f31c8c3d-02e1-4cb4-8088-38d64125e3f7@github.com>
 <naSLKPh3wQ3XFAH6Ax1wGMOTQ4z3nK2mB5DGzrzJl5o=.cec066fa-7c34-4df2-9235-79316b970efb@github.com>
 <Q8E7T0Yx7SG7fau8NPkhep7mLGVJc3YD1Vlj2g7qhZQ=.0bf7b2c5-664b-49c0-978d-67608b1a9cc4@github.com>
Message-ID: <VIOITnIKvUOdnoZF2-HVKu79wGrDgZE5hV8Sn678FMg=.9d7a0644-0c61-42a2-a2ee-c5457cb4c4bf@github.com>

On Wed, 6 Dec 2023 19:05:31 GMT, Phil Race <prr at openjdk.org> wrote:

>> Such change requires a [CSR](https://wiki.openjdk.org/display/csr) .
>> If we want to get this fix into JDK 22, we don't have time for CSR, since JDK 22 will be forked this Thursday.
>
> It is beyond that. It is an incompatible change. It will be rejected forever.

@prrace the related API already throw SecurityException if capture permission is not granted. moreover the API has been changed already in the pastr to accommodate that eg see

 https://docs.oracle.com/javase/8/docs/api/java/awt/Robot.html#getPixelColor-int-int-

VS

https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/Robot.html#getPixelColor(int,int)

and so it stands to reason that a similar solution can be found for this problem as well if there is a will to do so.

An exception seem to be the most logical solution here to me however it could be something different, like the approach you describe in JDK-8321475 (i cant comment there so commenting here instead). Either way, like i said, i firmly believe that the current API behavior is just plain wrong and potentially harmful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1417881950

From duke at openjdk.org  Wed Dec  6 20:07:36 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Wed, 6 Dec 2023 20:07:36 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <3oYrQJQd6ddztw3rvYvPVFko86BVvboscWVOssEsscA=.9ac97daf-9ada-4590-94df-7169533747cb@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
 <3oYrQJQd6ddztw3rvYvPVFko86BVvboscWVOssEsscA=.9ac97daf-9ada-4590-94df-7169533747cb@github.com>
Message-ID: <hD8tvnus5j_v-EDMcUaEVFK-fyawt0mXsccKIfVKhmk=.8274dc28-478b-40fd-b99b-b3b926bd8126@github.com>

On Wed, 6 Dec 2023 19:20:22 GMT, Phil Race <prr at openjdk.org> wrote:

>> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8321176: remove RuntimeException and address review comments
>
> src/java.desktop/unix/native/libawt_xawt/awt/screencast_pipewire.c line 102:
> 
>> 100:             if (screenProps->data->stream) {
>> 101:                 fp_pw_thread_loop_lock(pw.loop);
>> 102:                 fp_pw_stream_disconnect(screenProps->data->stream);
> 
> I had this disconnect inside the lock in an earlier PR 
> https://github.com/openjdk/jdk/pull/14428/files?diff=unified&w=0#diff-3ba5df79cdd3da36b21bf29b4e8de462dd61e6a21dfe0816e4d84c18bbfb76b2R92
> but then it was moved out of the lock in another PR to fix a bug https://bugs.openjdk.org/browse/JDK-8310334
> https://github.com/openjdk/jdk/pull/15250/files#diff-3ba5df79cdd3da36b21bf29b4e8de462dd61e6a21dfe0816e4d84c18bbfb76b2
> 
> 
> So how can it be right to put it back inside the lock ?

@prrace the related previous fixes didnt really fix anything and just re-shuffled things around to dodge specific problems encountered. the libpipewire API locking and signaling has been fundamentally broken before my patch for JDK-8320655. this is understandable given libpipewire lack of proper documentation in that area and no clear specs on when and how locking and signaling should be done.

this particular case you refer to you need to lock around disconnect bc if you don't there is a chance the disconnect API can fail here

https://github.com/PipeWire/pipewire/blob/master/src/pipewire/thread-loop.c#L100

since this is recursive lock, taking it explicitly before calling disconnect ensures this does not happen. if you test the old implementation with libpipewire debug enabled you would see it constantly failing in related API and complaining functions being called in the "wrong context", including this code in question.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16978#discussion_r1417918800

From achung at openjdk.org  Wed Dec  6 20:13:35 2023
From: achung at openjdk.org (Alisen Chung)
Date: Wed, 6 Dec 2023 20:13:35 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <h656ltpZagjfMixMMQPNwcDi71Br8SiElvGNjawdDlM=.f7695a82-8f85-468b-af1f-9176c31d06f8@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

Marked as reviewed by achung (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16960#pullrequestreview-1768534716

From prr at openjdk.org  Wed Dec  6 21:59:48 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Dec 2023 21:59:48 GMT
Subject: Integrated: 8320443: [macos] Test
 java/awt/print/PrinterJob/PrinterDevice.java fails on macOS
In-Reply-To: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
References: <mgjf5Tq73nn3pGUz4f_Q08VjeJpexJnji-nrGEU7LPY=.8901ae68-2d25-40e1-9efb-7d963d9208c3@github.com>
Message-ID: <_uuPxkb7O6Exrx0rWseA8vPVZRl_Dk7lrPLqhtW5HxQ=.ec2dd741-19f3-44fa-b127-196e6751f780@github.com>

On Tue, 21 Nov 2023 21:23:12 GMT, Phil Race <prr at openjdk.org> wrote:

> For as long as we've had the macOS port, it seems that queries on the GraphicsConfiguration associated with
> a printer would give you null for the defaultTransform.
> Clearly this API isn't a popular one to call in such a context else we'd have had lots of reports.
> We have a test that would have caught it except that until recently the macOS printing implementation
> was swallowing exceptions it should not.

This pull request has now been integrated.

Changeset: afb89640
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/afb896400bd194ef664ebad51c8d5d4c61a841d7
Stats:     78 lines in 4 files changed: 38 ins; 9 del; 31 mod

8320443: [macos] Test java/awt/print/PrinterJob/PrinterDevice.java fails on macOS

Reviewed-by: aivanov, azvegint

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

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

From prr at openjdk.org  Wed Dec  6 22:02:55 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Dec 2023 22:02:55 GMT
Subject: RFR: 8320365: IPPPrintService.getAttributes() causes blanket
 re-initialisation [v2]
In-Reply-To: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
References: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
Message-ID: <UunfP03tvCrHqbo8uxZ1URcnRHAZ5BZUnTniMAsHW6I=.fb845604-7ffe-4699-9fa2-3d4ca5b99c48@github.com>

> Whilst reviewing the fix for https://bugs.openjdk.org/browse/JDK-7001133 I realised that although the proposed
> changes there may help, the problem would be inconsequential except that if anything causes an app to
> call PrintService.getAttributes()  we will continually be re-initialising attributes, which causes IPPPrintService
> to keep creating new instances of CUPSPrinter which are then discarded and over-written.
> So update the implementation to only re-initialise the relevant attributes.

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

  8320365

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16752/files
  - new: https://git.openjdk.org/jdk/pull/16752/files/22a601fd..26823aa9

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

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

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

From prr at openjdk.org  Wed Dec  6 22:02:56 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 6 Dec 2023 22:02:56 GMT
Subject: Integrated: 8320365: IPPPrintService.getAttributes() causes blanket
 re-initialisation
In-Reply-To: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
References: <o81NZ23cQOMaBBkpbJkV5i1unr6Ws7CpmrnipP39W4g=.2b68b3ba-0489-4273-8b89-41f4a56cf403@github.com>
Message-ID: <ymS2R6JACztcblC9mswbk40XnsiLOPsvb40EhKCyS6c=.f387c880-4638-4f50-b6b0-9cbecc9be89e@github.com>

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

> Whilst reviewing the fix for https://bugs.openjdk.org/browse/JDK-7001133 I realised that although the proposed
> changes there may help, the problem would be inconsequential except that if anything causes an app to
> call PrintService.getAttributes()  we will continually be re-initialising attributes, which causes IPPPrintService
> to keep creating new instances of CUPSPrinter which are then discarded and over-written.
> So update the implementation to only re-initialise the relevant attributes.

This pull request has now been integrated.

Changeset: 91ffdfb1
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91ffdfb1fcacbb95b93491d412e506695198946e
Stats:     20 lines in 1 file changed: 10 ins; 0 del; 10 mod

8320365: IPPPrintService.getAttributes() causes blanket re-initialisation

Reviewed-by: aivanov, azvegint

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

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

From honkar at openjdk.org  Wed Dec  6 22:35:35 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 6 Dec 2023 22:35:35 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <0xGv8DdAKYVc8sUXzvE0T5VD8yqLy8LY15sYZ1CecMo=.90da90d4-34aa-4486-aafc-fb8f798df433@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

Tested on Ubuntu 23.04 with X11. Code and test changes look good. 
Copyright year needs to be updated for few test files.

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

Marked as reviewed by honkar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16960#pullrequestreview-1768744866

From aivanov at openjdk.org  Wed Dec  6 22:42:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 6 Dec 2023 22:42:34 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <46Es-wqs7SQ7qEHgMt3Low2k4aCFhp84Y0H0F8W9dWc=.4488ac37-c089-49a1-9148-7945050cfbd6@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16960#pullrequestreview-1768753364

From azvegint at openjdk.org  Thu Dec  7 03:37:53 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 7 Dec 2023 03:37:53 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04 [v2]
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <fgW3dfov9_CmQi8BMvszpM7lUOAjo5pK3vq-nucBdV0=.d31ff4bc-866b-4ed9-8d4a-2afd7ab5a3a9@github.com>

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

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

  copyright year updates

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16960/files
  - new: https://git.openjdk.org/jdk/pull/16960/files/2ed7c837..f2210a19

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

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

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

From azvegint at openjdk.org  Thu Dec  7 03:37:53 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 7 Dec 2023 03:37:53 GMT
Subject: Integrated: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04
In-Reply-To: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
Message-ID: <KtQAxjMuds1PRi8c5HaNN_AbDCTUN3qRU0gsdDDHhrU=.e3f9267e-99fa-4d7c-b4ce-358d8cc83be7@github.com>

On Mon, 4 Dec 2023 23:26:12 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

> The root of this issue is the incorrect calculation of window decoration insets.
> 
> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
> 
> This changed starting with Ubuntu 23.04:
> Now we can get several such notifications with zero window insets, and only then the correct value.
> 
> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
> 
> The solution is to change these insets on the fly, for now only for Mutter window manager. 
> The guessInsets for it have also been updated.
> 
> 
> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
> 
> Testing looks good.

This pull request has now been integrated.

Changeset: 632a3c56
Author:    Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/632a3c56e0626b4c4f79c8cb3d2ae312668d63fc
Stats:     42 lines in 8 files changed: 23 ins; 6 del; 13 mod

8305825: getBounds API returns wrong value resulting in multiple Regression Test Failures on Ubuntu 23.04

Reviewed-by: prr, achung, honkar, aivanov

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

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

From serb at openjdk.org  Thu Dec  7 05:09:42 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 7 Dec 2023 05:09:42 GMT
Subject: RFR: 8305825: getBounds API returns wrong value resulting in
 multiple Regression Test Failures on Ubuntu 23.04 [v2]
In-Reply-To: <fgW3dfov9_CmQi8BMvszpM7lUOAjo5pK3vq-nucBdV0=.d31ff4bc-866b-4ed9-8d4a-2afd7ab5a3a9@github.com>
References: <LRGaIN2pxBUD1cYnudmKVIMJFJpxr5EsfVwl3hBoQu8=.d6963390-dd9e-465f-8844-c337a2dd5831@github.com>
 <fgW3dfov9_CmQi8BMvszpM7lUOAjo5pK3vq-nucBdV0=.d31ff4bc-866b-4ed9-8d4a-2afd7ab5a3a9@github.com>
Message-ID: <7KizvE_c2oi0K1TkcWp7oPo5Y5VHrddMs7V3ZpmcyrI=.68a6602b-c236-48a0-b7df-1febadbfc42f@github.com>

On Thu, 7 Dec 2023 03:37:53 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> The root of this issue is the incorrect calculation of window decoration insets.
>> 
>> Previously we got non-zero window insets in the first PropertyNotify with [_NET_FRAME_EXTENTS](https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm45771211302000) atom, save them and never change them again.
>> 
>> This changed starting with Ubuntu 23.04:
>> Now we can get several such notifications with zero window insets, and only then the correct value.
>> 
>> Our code is not ready for this. It affects all our JDK. As a result, many tests fail on Ubuntu 23.04 and 23.10.
>> 
>> The solution is to change these insets on the fly, for now only for Mutter window manager. 
>> The guessInsets for it have also been updated.
>> 
>> 
>> This also means that some tests need some stabilization as they are not ready for such late arrival of window insets.
>> 
>> Testing looks good.
>
> Alexander Zvegintsev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year updates

Did you check that these empty values are actually correct? I mean the empty insets are actually real insets of the window which later changed to the correct one? Maybe we should report this upstream?

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

PR Comment: https://git.openjdk.org/jdk/pull/16960#issuecomment-1844431644

From rkannathpari at openjdk.org  Thu Dec  7 09:17:05 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 7 Dec 2023 09:17:05 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix [v2]
In-Reply-To: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
Message-ID: <EHfslq0NmzcHtTF8JPSJIlhytsAlzk_Esn8mbGXfRLQ=.1b7e9d62-df2d-4128-9ecd-0144fe81c606@github.com>

> Hi Reviewers, 
> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
> 
> Renjith.

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

  Added test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16895/files
  - new: https://git.openjdk.org/jdk/pull/16895/files/6910d9c6..b7faa3a7

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

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

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

From rkannathpari at openjdk.org  Thu Dec  7 09:20:34 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 7 Dec 2023 09:20:34 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix
In-Reply-To: <Sx8xe-Twvv70czoEW4Y5N6Wjm2VXpxmu14_tPWm4LbY=.f6fa57fd-6419-4b83-bd3c-a0bcc1b50df8@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
 <Sx8xe-Twvv70czoEW4Y5N6Wjm2VXpxmu14_tPWm4LbY=.f6fa57fd-6419-4b83-bd3c-a0bcc1b50df8@github.com>
Message-ID: <_5g2ZHT3M1m3Jw-c_1fc5EhKSZV1YmHhfsNpw2pgwjs=.75c60d73-0dd5-414b-827c-236ece294b2e@github.com>

On Thu, 30 Nov 2023 19:20:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Hi Reviewers, 
>> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
>> 
>> Renjith.
>
> Can this patch be covered by the new test?

Thank you @mrserb  and @aivanov-jdk for your review and suggestions,
      Successfully made a verification test for this case, please review and let me know your suggestions including test name and location.
Regards.
Renjith

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

PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1844973349

From serb at openjdk.org  Thu Dec  7 10:18:49 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 7 Dec 2023 10:18:49 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize call
 as COINIT_MULTITHREADED
Message-ID: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>

The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.

@aivanov-jdk please take a look.

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

Commit messages:
 - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED

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

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

From djelinski at openjdk.org  Thu Dec  7 10:18:55 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Dec 2023 10:18:55 GMT
Subject: RFR: 8321519: Typo in exception message
Message-ID: <ncdvYRrZSkwDc8RKZF_agd-HMhAcvdPlqvKVSpsy020=.f47547ca-e39c-4ac2-a4ff-d2858586756a@github.com>

This PR fixes a typo in exception message printed when `jdk.readPollers` or `jdk.writePollers` is not a power of two.

While at it, I searched the code for other instances of `vale`, and corrected them as well.

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

Commit messages:
 - Fix vale->value

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

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

From jpai at openjdk.org  Thu Dec  7 10:23:33 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Dec 2023 10:23:33 GMT
Subject: RFR: 8321519: Typo in exception message
In-Reply-To: <ncdvYRrZSkwDc8RKZF_agd-HMhAcvdPlqvKVSpsy020=.f47547ca-e39c-4ac2-a4ff-d2858586756a@github.com>
References: <ncdvYRrZSkwDc8RKZF_agd-HMhAcvdPlqvKVSpsy020=.f47547ca-e39c-4ac2-a4ff-d2858586756a@github.com>
Message-ID: <IENoYsnYsLqXmkVwJZtF5_sNvb7Ojdc_s7urmIh0kUE=.3e45eee5-e400-4758-b99e-0590c0960017@github.com>

On Thu, 7 Dec 2023 09:47:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR fixes a typo in exception message printed when `jdk.readPollers` or `jdk.writePollers` is not a power of two.
> 
> While at it, I searched the code for other instances of `vale`, and corrected them as well.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17016#pullrequestreview-1769739882

From aivanov at openjdk.org  Thu Dec  7 11:26:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Dec 2023 11:26:39 GMT
Subject: RFR: 8319925: CSS.BackgroundImage incorrectly uses double-checked
 locking [v3]
In-Reply-To: <h-QjB3VbNryANMLOUQBwxcfvHiAuDQaTg3DSNJiZ1lM=.cd2f88ba-f529-41a6-8856-ba78aa4e4489@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
 <h-QjB3VbNryANMLOUQBwxcfvHiAuDQaTg3DSNJiZ1lM=.cd2f88ba-f529-41a6-8856-ba78aa4e4489@github.com>
Message-ID: <mLyacI3k1y1CkP_KbqPq051_bC9OcW8PeceKh6BcuFU=.c6929d30-fa98-40c1-8766-6bcf9a93b09e@github.com>

On Wed, 6 Dec 2023 11:47:03 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.
>
> Prasanta Sadhukhan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Set loadedImage after image load

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16917#pullrequestreview-1769939544

From psadhukhan at openjdk.org  Thu Dec  7 11:44:46 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 7 Dec 2023 11:44:46 GMT
Subject: Integrated: 8319925: CSS.BackgroundImage incorrectly uses
 double-checked locking
In-Reply-To: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
References: <dhxCu30_3WFBJtcFGpysMzjkT5iHmh0z9SwFfLwNp54=.508507e1-e73c-4aad-82ed-4186dc2cc119@github.com>
Message-ID: <6_MxhTMjjz7UeZc3rHKlWbgCEJaWc-dd32NIiZxhDDM=.f5231336-c258-489d-8da9-8455461044ff@github.com>

On Fri, 1 Dec 2023 06:31:00 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> CSS.BackgroundImage.getImage uses double-checked locking but the loadedImage field isn't declared as volatile. Without the volatile modifier, double-checked locking implementation is broken.

This pull request has now been integrated.

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

8319925: CSS.BackgroundImage incorrectly uses double-checked locking

Reviewed-by: aivanov

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

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

From djelinski at openjdk.org  Thu Dec  7 12:02:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Dec 2023 12:02:42 GMT
Subject: RFR: 8321519: Typo in exception message
In-Reply-To: <ncdvYRrZSkwDc8RKZF_agd-HMhAcvdPlqvKVSpsy020=.f47547ca-e39c-4ac2-a4ff-d2858586756a@github.com>
References: <ncdvYRrZSkwDc8RKZF_agd-HMhAcvdPlqvKVSpsy020=.f47547ca-e39c-4ac2-a4ff-d2858586756a@github.com>
Message-ID: <kX2GGAiJS79cq8zDsvLDCbmwYR9-9fmTntdzfhffNu8=.0ea0e2ee-0642-488c-959c-0762c511ffbe@github.com>

On Thu, 7 Dec 2023 09:47:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR fixes a typo in exception message printed when `jdk.readPollers` or `jdk.writePollers` is not a power of two.
> 
> While at it, I searched the code for other instances of `vale`, and corrected them as well.

Thanks for the review. Given that it's a trivial change, I'm going to integrate it now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17016#issuecomment-1845214802

From djelinski at openjdk.org  Thu Dec  7 12:02:43 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 7 Dec 2023 12:02:43 GMT
Subject: Integrated: 8321519: Typo in exception message
In-Reply-To: <ncdvYRrZSkwDc8RKZF_agd-HMhAcvdPlqvKVSpsy020=.f47547ca-e39c-4ac2-a4ff-d2858586756a@github.com>
References: <ncdvYRrZSkwDc8RKZF_agd-HMhAcvdPlqvKVSpsy020=.f47547ca-e39c-4ac2-a4ff-d2858586756a@github.com>
Message-ID: <o4tluvCDE0-0XRzLunE4nC1r5gj_RzfsfLIXiuJQNkQ=.1eb643c5-7d77-49de-8564-d8b24a1791ce@github.com>

On Thu, 7 Dec 2023 09:47:16 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This PR fixes a typo in exception message printed when `jdk.readPollers` or `jdk.writePollers` is not a power of two.
> 
> While at it, I searched the code for other instances of `vale`, and corrected them as well.

This pull request has now been integrated.

Changeset: ead4fb14
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ead4fb1464e1560b64f78cc6241226bd6073b0d4
Stats:     3 lines in 3 files changed: 0 ins; 0 del; 3 mod

8321519: Typo in exception message

Reviewed-by: jpai

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

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

From alexsch at openjdk.org  Thu Dec  7 12:36:35 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Thu, 7 Dec 2023 12:36:35 GMT
Subject: RFR: 8318023: Implement IPP output-bin attribute extension on
 macOS [v3]
In-Reply-To: <YMk-iyHrx0htxEQwqlu3mLi6Rw1wNfADcPr11gQ4tw0=.d4fd6f5a-f98d-46cf-be54-fc0268586df3@github.com>
References: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
 <YMk-iyHrx0htxEQwqlu3mLi6Rw1wNfADcPr11gQ4tw0=.d4fd6f5a-f98d-46cf-be54-fc0268586df3@github.com>
Message-ID: <JHcXVoVcjOODPvBoEtKWgPaA4ChHeD3cmgDPKSdU1Ro=.d0f441a6-41ae-48a7-a81a-ce0650c3ebd5@github.com>

On Wed, 18 Oct 2023 17:36:49 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 three additional commits since the last revision:
> 
>  - Add empty lines between OutputBin constants
>  - Add Override annotation to OutputBin and CustomOutputBin methods
>  - Update OutputBin IPP Compatibility description

This is some investigation which I did for output bin attribute extension support on Linux.

[PostScript Language Reference](https://www.adobe.com/jp/print/postscript/pdfs/PLRM.pdf) manual third edition defines `OutputType` page device parameter with type `string` which represents special attributes of the output destination.

The example of `OutputType` usage I have found in [CUPS PPD Extensions](https://www.cups.org/doc/spec-ppd.html).
`OutputType` specifies the output type name, for example:

<</OutputType (Photo)>>setpagedevice


This is my implementation of adding `OutputType` parameter in PSPrinterJob: https://github.com/AlexanderScherbatiy/jdk/commit/92ce5b9e23e0338c0d1b49a653dbc67e0512bdc4

    protected void startDoc() throws PrinterException {
            ...
            String outputBin = getOutputBinValue(outputBinAttr);

            if (outputBin != null) {
                mPSStream.print(" /OutputType (" + outputBin + ") ");
            }


I tested it with Kyocera ECOSYS M8130cidn printer using Ubuntu 20.04.1 LTS.
The `ppdFindOption(ppd, "OutputBin")` function from `CUPSfuncs` returns two output bins for the Kyocera ECOSYS M8130cidn: 

text: Top, choice: Top
text: Stacker 1, choice: Stacker1
``` 
The result was that a page is printed to the same output tray (Top) no matter `Top` or `Stacker1` output bin is used for `OutputType` post script parameter.

First, I checked that printing a pdf file from the Unix PDF Viewer app using the system print dialog and choosing different output trays really prints pages to different output trays.

Second, I copied post script files sent by java program for printing from `/var/spool/cups` directory.
The post script file for `Top` output bin  contains:

%!PS-Adobe-3.0
...
%%BeginSetup
<< /PageSize [595.2755737304688 841.8897705078125] /DeferredMediaSelection true /ImagingBBox null /ManualFeed false /NumCopies 1 /OutputType (Top)  >> setpagedevice
%%EndSetup

which `/OutputType (Top)` setting looks correct. 
And for the `Stacker1` output bin:

%%BeginSetup
<< /PageSize [595.2755737304688 841.8897705078125] /DeferredMediaSelection true /ImagingBBox null /ManualFeed false /NumCopies 1 /OutputType (Stacker1)  >> setpagedevice
%%EndSetup

the setting for output bin is `/OutputType (Stacker1)`.

The file which sends the PDF Viewer for printing includes `%PDF-1.5` version and I was not able to find the parameter corresponding to the selected output bin even if I convert the file from pdf to ps format using `pdf2ps` tool which generates file in `%!PS-Adobe-3.0` fromat.

It is not clear for me why `/OutputType (Stacker1)` parameter does not work and is there a way to take the output bin parameter which Linux native printer dialog use to print a document to the `Stacker 1` tray for the Kyocera ECOSYS M8130cidn printer.

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?

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

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

From duke at openjdk.org  Thu Dec  7 15:38:48 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Thu, 7 Dec 2023 15:38:48 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <aSRI0JBfQYi-NDq8VfdOD_U6CMojoTtyZQxPoTzWRv0=.f50cb0ae-abea-4814-9606-d369bf12312b@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
 <aSRI0JBfQYi-NDq8VfdOD_U6CMojoTtyZQxPoTzWRv0=.f50cb0ae-abea-4814-9606-d369bf12312b@github.com>
Message-ID: <HGjZfRvfIfg7gsI3Iuail0W00EdV2OQsZI3kbGQaN7s=.35634185-040e-4ff0-bea9-1e48bc9f0d90@github.com>

On Wed, 6 Dec 2023 18:04:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8321176: remove RuntimeException and address review comments
>
> Looks good to me.
> 
>> can you please file a bug based on my description above ?
> 
> Filed the [JDK-8321475](https://bugs.openjdk.org/browse/JDK-8321475) for this
> 
>> and also something i thought i should mention wrt doCleanup() function. it might be a good idea to protect it with a mutex or something. it does look safe ATM but i haven't looked at related libpipewire internals to assert that with full certainty. there perhaps could be a situation where doCleanup() is called internally but also from java cleanup thread (the one that sleeps for 2 seconds) and if they interleave/race it might cause unexpected behavior or crash in libpipewire as its rather sensible in terms of teardown sequence (i've seen its crashing due to that in my testing and thats why i have reshuffled some related calls in this patch). anyways, this is something to look into and check.
> 
> Sure, we should revisit it later.

@azvegint @prrace unless there are any outstanding issues with this patch that need addressing/correcting can you please sponsor it for me?

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

PR Comment: https://git.openjdk.org/jdk/pull/16978#issuecomment-1845566863

From aivanov at openjdk.org  Thu Dec  7 15:54:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 7 Dec 2023 15:54:46 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED
In-Reply-To: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
Message-ID: <DcZqk4aMxWbe7jaPNcDXkvfi6ULY_BkvjhMTiKZSSn0=.dda32696-e9f6-4307-97f1-c0bbd332f735@github.com>

On Thu, 7 Dec 2023 03:03:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
> 
> @aivanov-jdk please take a look.

src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp line 99:

> 97:             ::CoUninitialize();
> 98:         }
> 99:     }

I'm unsure this is the right thing to do. The documentation for [`ShellExecute`](https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew) mentions, <q cite="https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew">Some Shell extensions require the COM single-threaded apartment (STA) type.</q> I believe this is true for most shell extensions because they deal with UI.

At the same time, <q cite="https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew">There are certainly instances where `ShellExecute` does not use one of these types of Shell extension and those instances would not require COM to be initialized at all.</q>

So, if the current thread initialised COM as MTA, the call to `ShellExecute` would likely fail if it needs COM to perform the requested action as it requires STA in majority of cases.

A workaround would be to hand off the task to a special thread, or just fail straight away as the code does right now. Otherwise, the errors could be sporadic and unpredictable: some calls complete successfully whereas others fail.

Could this code use [`ComInvoker`](https://github.com/openjdk/jdk/blob/58530f4098538f490cfea58f2382d0997841c171/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java#L572) from `Win32ShellFolderManager2`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17010#discussion_r1419118913

From azvegint at openjdk.org  Thu Dec  7 17:54:13 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Thu, 7 Dec 2023 17:54:13 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <aSRI0JBfQYi-NDq8VfdOD_U6CMojoTtyZQxPoTzWRv0=.f50cb0ae-abea-4814-9606-d369bf12312b@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
 <aSRI0JBfQYi-NDq8VfdOD_U6CMojoTtyZQxPoTzWRv0=.f50cb0ae-abea-4814-9606-d369bf12312b@github.com>
Message-ID: <w5Cba5432_5sl6w3gdKHryS0f7er6KRa51R__UjFH9A=.60f6ca93-2f55-4663-94c1-d4c9b3485ac2@github.com>

On Wed, 6 Dec 2023 18:04:59 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8321176: remove RuntimeException and address review comments
>
> Looks good to me.
> 
>> can you please file a bug based on my description above ?
> 
> Filed the [JDK-8321475](https://bugs.openjdk.org/browse/JDK-8321475) for this
> 
>> and also something i thought i should mention wrt doCleanup() function. it might be a good idea to protect it with a mutex or something. it does look safe ATM but i haven't looked at related libpipewire internals to assert that with full certainty. there perhaps could be a situation where doCleanup() is called internally but also from java cleanup thread (the one that sleeps for 2 seconds) and if they interleave/race it might cause unexpected behavior or crash in libpipewire as its rather sensible in terms of teardown sequence (i've seen its crashing due to that in my testing and thats why i have reshuffled some related calls in this patch). anyways, this is something to look into and check.
> 
> Sure, we should revisit it later.

> @azvegint @prrace unless there are any outstanding issues with this patch that need addressing/correcting can you please sponsor it for me?

In the client, we have a rule that PR requires two people approval for integration (despite the hard rule of 1 mentioned in the header). 
So I am waiting for another approval.

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

PR Comment: https://git.openjdk.org/jdk/pull/16978#issuecomment-1845837937

From prr at openjdk.org  Thu Dec  7 18:48:22 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Dec 2023 18:48:22 GMT
Subject: RFR: 8312307: Obsoleted code in hb-jdk-font.cc
Message-ID: <mVwYYfpVdFz6g8imJGHGp_pfNoEaiMiO7JXf88AraLw=.e38b354b-dede-47db-8f2e-be835bc44011@github.com>

Clean up some un-used code in the 2D native font code that interfaces to libharfbuzz

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

Commit messages:
 - 8312307

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

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

From prr at openjdk.org  Thu Dec  7 19:55:11 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Dec 2023 19:55:11 GMT
Subject: RFR: 8286827: BogusColorSpace methods return wrong array
Message-ID: <c25VUl037BDG4AiibshLbSgu8ryVEyN7F7XqlRQVu-g=.2872d475-989b-4d6a-bfdd-05923cdf67a8@github.com>

The conversion methods in this class return the wrong array.

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

Commit messages:
 - 8286827

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

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

From prr at openjdk.org  Thu Dec  7 20:02:45 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Dec 2023 20:02:45 GMT
Subject: RFR: 8288712: Typo in javadoc in javax.imageio.ImageReader.java
Message-ID: <OiSm8StCyvpG1FYw0DP7c48szyUPISjazGqFiml7DyY=.a4b6e814-6379-4ded-b632-fdbff1eba96f@github.com>

As can be seen here
https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/imageio/ImageReader.html#computeRegions(javax.imageio.ImageReadParam,int,int,java.awt.image.BufferedImage,java.awt.Rectangle,java.awt.Rectangle)

There's an extra '>' in the javadoc source with the result being
"The getSourceRegion> method may be used if only source clipping is desired."

fix is to remove it.

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

Commit messages:
 - 8288712

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

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

From iris at openjdk.org  Thu Dec  7 20:58:19 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 7 Dec 2023 20:58:19 GMT
Subject: RFR: 8288712: Typo in javadoc in javax.imageio.ImageReader.java
In-Reply-To: <OiSm8StCyvpG1FYw0DP7c48szyUPISjazGqFiml7DyY=.a4b6e814-6379-4ded-b632-fdbff1eba96f@github.com>
References: <OiSm8StCyvpG1FYw0DP7c48szyUPISjazGqFiml7DyY=.a4b6e814-6379-4ded-b632-fdbff1eba96f@github.com>
Message-ID: <WkfD_ZEAuW1Vpla6TJ7vaB9O_rWtJ7JC3UZ-wmDUbO8=.8eb4437f-f0c4-49c8-9f37-7de226c89986@github.com>

On Thu, 7 Dec 2023 19:56:07 GMT, Phil Race <prr at openjdk.org> wrote:

> As can be seen here
> https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/imageio/ImageReader.html#computeRegions(javax.imageio.ImageReadParam,int,int,java.awt.image.BufferedImage,java.awt.Rectangle,java.awt.Rectangle)
> 
> There's an extra '>' in the javadoc source with the result being
> "The getSourceRegion> method may be used if only source clipping is desired."
> 
> fix is to remove it.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17025#pullrequestreview-1771116039

From prr at openjdk.org  Thu Dec  7 21:08:24 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Dec 2023 21:08:24 GMT
Subject: Integrated: 8288712: Typo in javadoc in javax.imageio.ImageReader.java
In-Reply-To: <OiSm8StCyvpG1FYw0DP7c48szyUPISjazGqFiml7DyY=.a4b6e814-6379-4ded-b632-fdbff1eba96f@github.com>
References: <OiSm8StCyvpG1FYw0DP7c48szyUPISjazGqFiml7DyY=.a4b6e814-6379-4ded-b632-fdbff1eba96f@github.com>
Message-ID: <tjeh5Dmo2gXKSe3iU7FHmnnJFDXxGYtg8w8CitYpYXE=.f78aec88-71d8-4d21-b08c-ed8c749fa691@github.com>

On Thu, 7 Dec 2023 19:56:07 GMT, Phil Race <prr at openjdk.org> wrote:

> As can be seen here
> https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/imageio/ImageReader.html#computeRegions(javax.imageio.ImageReadParam,int,int,java.awt.image.BufferedImage,java.awt.Rectangle,java.awt.Rectangle)
> 
> There's an extra '>' in the javadoc source with the result being
> "The getSourceRegion> method may be used if only source clipping is desired."
> 
> fix is to remove it.

This pull request has now been integrated.

Changeset: 959a443a
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/959a443a9eb8f1ebc1335fdd86d421154bd71491
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288712: Typo in javadoc in javax.imageio.ImageReader.java

Reviewed-by: iris

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

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

From serb at openjdk.org  Thu Dec  7 22:57:52 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 7 Dec 2023 22:57:52 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
Message-ID: <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>

> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
> 
> @aivanov-jdk please take a look.

Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:

 - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED
 - Revert "6508941: java.awt.Desktop.open causes VM to crash with video files sporadically"
   
   This reverts commit 85269470
 - Revert "8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED"
   
   This reverts commit 4908d9c220950683d3a5010d12ab756eff6b6fa7.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17010/files
  - new: https://git.openjdk.org/jdk/pull/17010/files/4908d9c2..edcda08c

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

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

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

From serb at openjdk.org  Thu Dec  7 22:57:53 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 7 Dec 2023 22:57:53 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <DcZqk4aMxWbe7jaPNcDXkvfi6ULY_BkvjhMTiKZSSn0=.dda32696-e9f6-4307-97f1-c0bbd332f735@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <DcZqk4aMxWbe7jaPNcDXkvfi6ULY_BkvjhMTiKZSSn0=.dda32696-e9f6-4307-97f1-c0bbd332f735@github.com>
Message-ID: <UPPOM9dZtQuxm20NTtL8KFtiMkggQVcq3BaVUwOm-88=.3fcd0ed8-2dc9-4f83-9ed8-3ab858f161ee@github.com>

On Thu, 7 Dec 2023 15:11:24 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED
>>  - Revert "6508941: java.awt.Desktop.open causes VM to crash with video files sporadically"
>>    
>>    This reverts commit 85269470
>>  - Revert "8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED"
>>    
>>    This reverts commit 4908d9c220950683d3a5010d12ab756eff6b6fa7.
>
> src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp line 99:
> 
>> 97:             ::CoUninitialize();
>> 98:         }
>> 99:     }
> 
> I'm unsure this is the right thing to do. The documentation for [`ShellExecute`](https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew) mentions, <q cite="https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew">Some Shell extensions require the COM single-threaded apartment (STA) type.</q> I believe this is true for most shell extensions because they deal with UI.
> 
> At the same time, <q cite="https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew">There are certainly instances where `ShellExecute` does not use one of these types of Shell extension and those instances would not require COM to be initialized at all.</q>
> 
> So, if the current thread initialised COM as MTA, the call to `ShellExecute` would likely fail if it needs COM to perform the requested action as it requires STA in majority of cases.
> 
> A workaround would be to hand off the task to a special thread, or just fail straight away as the code does right now. Otherwise, the errors could be sporadic and unpredictable: some calls complete successfully whereas others fail.
> 
> Could this code use [`ComInvoker`](https://github.com/openjdk/jdk/blob/58530f4098538f490cfea58f2382d0997841c171/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java#L572) from `Win32ShellFolderManager2`?

You are right! This reminded me why initial implementation uses COINIT_APARTMENTTHREADED. So jump on another thread seems the only possible solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17010#discussion_r1419743727

From bpb at openjdk.org  Thu Dec  7 23:07:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Dec 2023 23:07:15 GMT
Subject: RFR: 8286827: BogusColorSpace methods return wrong array
In-Reply-To: <c25VUl037BDG4AiibshLbSgu8ryVEyN7F7XqlRQVu-g=.2872d475-989b-4d6a-bfdd-05923cdf67a8@github.com>
References: <c25VUl037BDG4AiibshLbSgu8ryVEyN7F7XqlRQVu-g=.2872d475-989b-4d6a-bfdd-05923cdf67a8@github.com>
Message-ID: <JoW1hW6Cwf1Sd8urmt72OrYG1fYZu7qtrlP6b_phsO4=.e1aaeb64-b780-47a0-86ab-623942462ad8@github.com>

On Thu, 7 Dec 2023 19:47:22 GMT, Phil Race <prr at openjdk.org> wrote:

> The conversion methods in this class return the wrong array.

Looks fine.

Probably corrects a faux pas of mine from about 18 years ago.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17024#pullrequestreview-1771270530

From serb at openjdk.org  Thu Dec  7 23:27:17 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 7 Dec 2023 23:27:17 GMT
Subject: RFR: 8286827: BogusColorSpace methods return wrong array
In-Reply-To: <c25VUl037BDG4AiibshLbSgu8ryVEyN7F7XqlRQVu-g=.2872d475-989b-4d6a-bfdd-05923cdf67a8@github.com>
References: <c25VUl037BDG4AiibshLbSgu8ryVEyN7F7XqlRQVu-g=.2872d475-989b-4d6a-bfdd-05923cdf67a8@github.com>
Message-ID: <arSEXHjmWmzQ3rYiHI9mrr-A5z-TGJrU-TiOsDqfZcc=.b7b7d6c4-b298-47b1-a813-e0034ca0b7c9@github.com>

On Thu, 7 Dec 2023 19:47:22 GMT, Phil Race <prr at openjdk.org> wrote:

> The conversion methods in this class return the wrong array.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17024#pullrequestreview-1771287026

From prr at openjdk.org  Thu Dec  7 23:36:22 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 7 Dec 2023 23:36:22 GMT
Subject: Integrated: 8286827: BogusColorSpace methods return wrong array
In-Reply-To: <c25VUl037BDG4AiibshLbSgu8ryVEyN7F7XqlRQVu-g=.2872d475-989b-4d6a-bfdd-05923cdf67a8@github.com>
References: <c25VUl037BDG4AiibshLbSgu8ryVEyN7F7XqlRQVu-g=.2872d475-989b-4d6a-bfdd-05923cdf67a8@github.com>
Message-ID: <baGrWMlYQp-z6gfHrzJl7kK21ZqZUKWogj03WcPSY9Y=.4ff9f069-9667-4425-81ea-8189d108f488@github.com>

On Thu, 7 Dec 2023 19:47:22 GMT, Phil Race <prr at openjdk.org> wrote:

> The conversion methods in this class return the wrong array.

This pull request has now been integrated.

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

8286827: BogusColorSpace methods return wrong array

Reviewed-by: bpb, serb

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

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

From serb at openjdk.org  Fri Dec  8 00:11:12 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 8 Dec 2023 00:11:12 GMT
Subject: RFR: 8312307: Obsoleted code in hb-jdk-font.cc
In-Reply-To: <mVwYYfpVdFz6g8imJGHGp_pfNoEaiMiO7JXf88AraLw=.e38b354b-dede-47db-8f2e-be835bc44011@github.com>
References: <mVwYYfpVdFz6g8imJGHGp_pfNoEaiMiO7JXf88AraLw=.e38b354b-dede-47db-8f2e-be835bc44011@github.com>
Message-ID: <3O-OWfEZ_oBoOPj2_dUj8JEn79JmcPHiCr3l_JgGIGM=.6cc0f5d8-c490-4be0-bec0-840b0c495e78@github.com>

On Thu, 7 Dec 2023 18:41:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Clean up some un-used code in the 2D native font code that interfaces to libharfbuzz

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17022#pullrequestreview-1771320458

From rkannathpari at openjdk.org  Fri Dec  8 03:29:31 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 8 Dec 2023 03:29:31 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java
Message-ID: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>

Hi Reviewers,

Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. Please review and let me know your suggestions.

Regards,
Renjith.

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

Commit messages:
 - Updated font and copyright year
 - Removed commented code
 - JDK-8320343 : Generate GIF images for AbstractButton/5049549/bug5049549.java

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

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

From duke at openjdk.org  Fri Dec  8 08:48:57 2023
From: duke at openjdk.org (vtstydev)
Date: Fri, 8 Dec 2023 08:48:57 GMT
Subject: RFR: JDK-8307246 : Update for sun.print.RasterPrinterJob in
 banded-raster printing loop
Message-ID: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>

More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper.

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

Commit messages:
 - More correct way to take in consideration nonzero PHYSICALOFFSETX,PHYSICALOFFSETY of device for banded-raster printing loop

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

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

From duke at openjdk.org  Fri Dec  8 12:26:32 2023
From: duke at openjdk.org (duke)
Date: Fri, 8 Dec 2023 12:26:32 GMT
Subject: Withdrawn: JDK-8302618: [macOS] Problem typing uppercase letters with
 java.awt.Robot when moving mouse
In-Reply-To: <ZqhIYTFuyW36WTnzIX3oIqcYqZQ3F5OwsRvGstrIOdk=.d3ddc124-079a-483e-9f7a-17cf49443096@github.com>
References: <ZqhIYTFuyW36WTnzIX3oIqcYqZQ3F5OwsRvGstrIOdk=.d3ddc124-079a-483e-9f7a-17cf49443096@github.com>
Message-ID: <KyyaZO5e7zWtx420NErkhTmiqreBBT7DxNMIVKbm55A=.f0df8207-c562-4ca5-abdc-bce9630c75d9@github.com>

On Fri, 30 Jun 2023 22:29:05 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> **Problem:**
> 
> On macOS, Robot erroneously produces lowercase letter when mouse is moved (manually) in unison with Robot's keyEvents. This issue was originally logged by a developer of an on-screen accessibility keyboard  - TouchBoard. Originally reported at https://github.com/adoptium/adoptium-support/issues/710
> 
> This issue is reproducible on JDK versions 22 to 11, but works fine on JDK-8. (details below) 
> 
> This issue is not restricted to the Shift modifier key and causes problems with other modifier keys as well and in some scenarios without any external mouse movement.
> 
> - This works correctly on JDK-8 up to JDK-9+129 when Accessibility APIs (AXUIElementCreateSystemWide/ AXUIElementPostKeyboardEvent) were used. Later on it was changed to CGEvents. 
> 
> - With the present code, the issue occurs at [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.)  The flags gets reset or cleared when mouse is moved physically in unison with Robot's key events.
> 
> - The physical mouse movement causes the event flags to be reset. 
> 
> **Impact:**
> 
> Modifier keys don't work as expected when using Robot with any simultaneous physical mouse movement and in case of TouchBoard, this behavior breaks the usability of the on-screen a11y keyboard. There is no known workaround for this particular use case except for reverting to JDK-8. More details on this use case [here.](https://github.com/adoptium/adoptium-support/issues/710#issuecomment-1594103280)
> 
> **Proposed Fix:**
> 
> - In order to avoid resetting of the CGEventFlags here [CRobot.m#L295](https://github.com/openjdk/jdk/blob/ac6af6a64099c182e982a0a718bc1b780cef616e/src/java.desktop/macosx/native/libawt_lwawt/awt/CRobot.m#L295.), the CGEvent flag state is obtained in `initRobot` (stored in initFlags) which is later used within `CRobot_keyEvent`.
> 
> - The incoming keyCode is used to determine whether it is a modifier key and the corresponding modifierFlagMask is either added or cleared from the initFlags based on whether the modifier key was pressed or released.
> 
> - Finally, only the required and known flag bits from initFlag are copied over to local flag which is used in `CGEventSetFlags()`.
> 
> **Testing:**
> 
> The newly added test - RobotModifierMaskTest.java tests for Shift, Caps, Control, Option and Command keys.
> The test runs in 2 modes - as automated and manual test.
> 
> CASE 1 :  As automated test. No user interaction needed.
> CASE 2 :  When r...

This pull request has been closed without being integrated.

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

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

From bourges.laurent at gmail.com  Fri Dec  8 14:27:06 2023
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 8 Dec 2023 15:27:06 +0100
Subject: RenderPerf 23.11
Message-ID: <CAKjRUT6YsrO0H6QSC3RYX9Ck51e7NX+1AjRAwPwaXawb1sfUqg@mail.gmail.com>

Hi,

I forked & improved RenderPerf test from jetbrains runtime ie
openjdk/test/jdk/performance...

See RenderPerf 23.11 release for new features:
https://github.com/bourgesl/RenderPerf/releases/tag/v23_11

FYI I will fix minor things and will contribute it back to openjdk as PR
for early 2024.

Cheers,
Laurent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231208/e51325ad/attachment.htm>

From volker.simonis at gmail.com  Fri Dec  8 14:39:14 2023
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 8 Dec 2023 15:39:14 +0100
Subject: RenderPerf 23.11
In-Reply-To: <CAKjRUT6YsrO0H6QSC3RYX9Ck51e7NX+1AjRAwPwaXawb1sfUqg@mail.gmail.com>
References: <CAKjRUT6YsrO0H6QSC3RYX9Ck51e7NX+1AjRAwPwaXawb1sfUqg@mail.gmail.com>
Message-ID: <CA+3eh12Ch3X9p8XQoLJavH7pAfUkA9OCCXF2pxrh_T_1ictzyw@mail.gmail.com>

Hi Laurent,

I don't think you can contribute somebody else's code to OpenJDK. All
OpenJDK contributions are done under OCA, but under OCA you can only
contribute code for which you own the copyright. So in this case, JetBrains
would have to contribute the code.

I understand that it is just a test, but still.

Best regards,
Volker

Laurent Bourg?s <bourges.laurent at gmail.com> schrieb am Fr., 8. Dez. 2023,
15:27:

> Hi,
>
> I forked & improved RenderPerf test from jetbrains runtime ie
> openjdk/test/jdk/performance...
>
> See RenderPerf 23.11 release for new features:
> https://github.com/bourgesl/RenderPerf/releases/tag/v23_11
>
> FYI I will fix minor things and will contribute it back to openjdk as PR
> for early 2024.
>
> Cheers,
> Laurent
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231208/79237eea/attachment.htm>

From bourges.laurent at gmail.com  Fri Dec  8 15:07:18 2023
From: bourges.laurent at gmail.com (=?UTF-8?Q?Laurent_Bourg=C3=A8s?=)
Date: Fri, 8 Dec 2023 16:07:18 +0100
Subject: RenderPerf 23.11
In-Reply-To: <CA+3eh12Ch3X9p8XQoLJavH7pAfUkA9OCCXF2pxrh_T_1ictzyw@mail.gmail.com>
References: <CAKjRUT6YsrO0H6QSC3RYX9Ck51e7NX+1AjRAwPwaXawb1sfUqg@mail.gmail.com>
 <CA+3eh12Ch3X9p8XQoLJavH7pAfUkA9OCCXF2pxrh_T_1ictzyw@mail.gmail.com>
Message-ID: <CAKjRUT4mOL=_ebkT9WxbXzgizX8TAXG3KADnXdSoZQ51dEGJXA@mail.gmail.com>

Hi volker,

I did work as a contractor for JetBrains on this changes so I do not see
any IP issue as I am an OpenJDK contributor and the JetBrains company too.
See https://github.com/JetBrains/JetBrainsRuntime/tree/lbourges/renderperf

I can use my jetbrains.com email but it would requires me to create another
github account, that's painful.

Thanks for asking this question,
Laurent


Le ven. 8 d?c. 2023, 15:39, Volker Simonis <volker.simonis at gmail.com> a
?crit :

> Hi Laurent,
>
> I don't think you can contribute somebody else's code to OpenJDK. All
> OpenJDK contributions are done under OCA, but under OCA you can only
> contribute code for which you own the copyright. So in this case, JetBrains
> would have to contribute the code.
>
> I understand that it is just a test, but still.
>
> Best regards,
> Volker
>
> Laurent Bourg?s <bourges.laurent at gmail.com> schrieb am Fr., 8. Dez. 2023,
> 15:27:
>
>> Hi,
>>
>> I forked & improved RenderPerf test from jetbrains runtime ie
>> openjdk/test/jdk/performance...
>>
>> See RenderPerf 23.11 release for new features:
>> https://github.com/bourgesl/RenderPerf/releases/tag/v23_11
>>
>> FYI I will fix minor things and will contribute it back to openjdk as PR
>> for early 2024.
>>
>> Cheers,
>> Laurent
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231208/edf1e607/attachment.htm>

From aivanov at openjdk.org  Fri Dec  8 15:40:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Dec 2023 15:40:19 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
Message-ID: <OBEncTd_fK2jO_0Tn7WiW1IDjS3MMXkNXZVid7KJiEU=.e0e2bde9-6435-4ebb-9392-135bea5b30d7@github.com>

On Thu, 7 Dec 2023 22:57:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
>> 
>> @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED
>  - Revert "6508941: java.awt.Desktop.open causes VM to crash with video files sporadically"
>    
>    This reverts commit 85269470
>  - Revert "8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED"
>    
>    This reverts commit 4908d9c220950683d3a5010d12ab756eff6b6fa7.

Looks good to me.

src/java.desktop/windows/classes/sun/awt/windows/WDesktopPeer.java line 120:

> 118:         if (errmsg != null) {
> 119:             throw new IOException("Failed to " + verb + " " + uri +
> 120:                                   ". Error message: " + errmsg);

Suggestion:

            throw new IOException("Failed to " + verb + " " + uri
                                  + ". Error message: " + errmsg);

I prefer this style where the operator is wrapped to the continuation line, it's this style that is recommended by [Java Style Guidelines](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-wrapping-lines) (see Wrapping Expressions section; unfortunately, there are no anchors for level 4 headers) as well as by the [original Code Conventions](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#272), but the formatting is absolutely in the HTML version.

At the time, I like your new alignment.

As far as I know, there are no agreed code style convention that clientlibs follow?

src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp line 89:

> 87:     unsigned oldcontrol87 = _control87(0, 0);
> 88:     HINSTANCE retval = ::ShellExecute(NULL, verb_c, fileOrUri_c, NULL, NULL,
> 89:                                       SW_SHOWNORMAL);

Leave it unmodified, perhaps?

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17010#pullrequestreview-1772646683
PR Review Comment: https://git.openjdk.org/jdk/pull/17010#discussion_r1420667007
PR Review Comment: https://git.openjdk.org/jdk/pull/17010#discussion_r1420664568

From aivanov at openjdk.org  Fri Dec  8 16:06:17 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Dec 2023 16:06:17 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
Message-ID: <6jsdLXaXrts3QBNba1_9UEflVBfPbL_XUwprUSCpMFw=.379a0c52-52de-4167-bd6c-ba0970bae6c4@github.com>

On Thu, 7 Dec 2023 22:57:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
>> 
>> @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED
>  - Revert "6508941: java.awt.Desktop.open causes VM to crash with video files sporadically"
>    
>    This reverts commit 85269470
>  - Revert "8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED"
>    
>    This reverts commit 4908d9c220950683d3a5010d12ab756eff6b6fa7.

Please, update the copyright year in `WDesktopPeer.java`.

src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp line 2:

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

Suggestion:

 * Copyright (c) 2005, 2023, Oracle and/or its affiliates. All rights reserved.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17010#pullrequestreview-1772707943
PR Review Comment: https://git.openjdk.org/jdk/pull/17010#discussion_r1420705243

From aivanov at openjdk.org  Fri Dec  8 16:06:20 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Dec 2023 16:06:20 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <UPPOM9dZtQuxm20NTtL8KFtiMkggQVcq3BaVUwOm-88=.3fcd0ed8-2dc9-4f83-9ed8-3ab858f161ee@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <DcZqk4aMxWbe7jaPNcDXkvfi6ULY_BkvjhMTiKZSSn0=.dda32696-e9f6-4307-97f1-c0bbd332f735@github.com>
 <UPPOM9dZtQuxm20NTtL8KFtiMkggQVcq3BaVUwOm-88=.3fcd0ed8-2dc9-4f83-9ed8-3ab858f161ee@github.com>
Message-ID: <BIWX_h5QlxlslL3u3Bdadlu_5pNsotbDwa1rPoLXWjE=.aa58965f-b416-4bab-8832-c1c0152c117d@github.com>

On Thu, 7 Dec 2023 22:53:25 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp line 99:
>> 
>>> 97:             ::CoUninitialize();
>>> 98:         }
>>> 99:     }
>> 
>> I'm unsure this is the right thing to do. The documentation for [`ShellExecute`](https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew) mentions, <q cite="https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew">Some Shell extensions require the COM single-threaded apartment (STA) type.</q> I believe this is true for most shell extensions because they deal with UI.
>> 
>> At the same time, <q cite="https://learn.microsoft.com/en-us/windows/win32/api/shellapi/nf-shellapi-shellexecutew">There are certainly instances where `ShellExecute` does not use one of these types of Shell extension and those instances would not require COM to be initialized at all.</q>
>> 
>> So, if the current thread initialised COM as MTA, the call to `ShellExecute` would likely fail if it needs COM to perform the requested action as it requires STA in majority of cases.
>> 
>> A workaround would be to hand off the task to a special thread, or just fail straight away as the code does right now. Otherwise, the errors could be sporadic and unpredictable: some calls complete successfully whereas others fail.
>> 
>> Could this code use [`ComInvoker`](https://github.com/openjdk/jdk/blob/58530f4098538f490cfea58f2382d0997841c171/src/java.desktop/windows/classes/sun/awt/shell/Win32ShellFolderManager2.java#L572) from `Win32ShellFolderManager2`?
>
> You are right! This reminded me why initial implementation uses COINIT_APARTMENTTHREADED. So jump on another thread seems the only possible solution.

The confusion could come from #14898 where [`RPC_E_CHANGED_MODE` doesn't prevent](https://github.com/openjdk/jdk/pull/14898#issuecomment-1748967705) us from calling DirectSound API which supports both MTA and STA.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17010#discussion_r1420712819

From aivanov at openjdk.org  Fri Dec  8 16:09:12 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Dec 2023 16:09:12 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
Message-ID: <g-sWuLbMXpMQJrhLGPVHzE1dz0kNYK1mZRwNlzjyz2Q=.69e0e342-6f01-49f6-bcf6-dc20c2d4d01e@github.com>

On Thu, 7 Dec 2023 22:57:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
>> 
>> @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED
>  - Revert "6508941: java.awt.Desktop.open causes VM to crash with video files sporadically"
>    
>    This reverts commit 85269470
>  - Revert "8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED"
>    
>    This reverts commit 4908d9c220950683d3a5010d12ab756eff6b6fa7.

I submitted [JDK-8321602](https://bugs.openjdk.org/browse/JDK-8321602) for creating a manual test for this failure. I'd like to explore this possibility? and it's a good opportunity to give a try to Foreign Function & Memory API.

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

PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1847452790

From aivanov at openjdk.org  Fri Dec  8 16:18:15 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Dec 2023 16:18:15 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <OBEncTd_fK2jO_0Tn7WiW1IDjS3MMXkNXZVid7KJiEU=.e0e2bde9-6435-4ebb-9392-135bea5b30d7@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
 <OBEncTd_fK2jO_0Tn7WiW1IDjS3MMXkNXZVid7KJiEU=.e0e2bde9-6435-4ebb-9392-135bea5b30d7@github.com>
Message-ID: <ojn_-Z3-KJe5VO7Hn-H1U0q18UEoYHdUQqtzPbuPMQc=.06459e75-f845-43f2-9f13-17cc1fafa167@github.com>

On Fri, 8 Dec 2023 15:36:40 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED
>>  - Revert "6508941: java.awt.Desktop.open causes VM to crash with video files sporadically"
>>    
>>    This reverts commit 85269470
>>  - Revert "8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED"
>>    
>>    This reverts commit 4908d9c220950683d3a5010d12ab756eff6b6fa7.
>
> src/java.desktop/windows/classes/sun/awt/windows/WDesktopPeer.java line 120:
> 
>> 118:         if (errmsg != null) {
>> 119:             throw new IOException("Failed to " + verb + " " + uri +
>> 120:                                   ". Error message: " + errmsg);
> 
> Suggestion:
> 
>             throw new IOException("Failed to " + verb + " " + uri
>                                   + ". Error message: " + errmsg);
> 
> I prefer this style where the operator is wrapped to the continuation line, it's this style that is recommended by [Java Style Guidelines](https://cr.openjdk.org/~alundblad/styleguide/index-v6.html#toc-wrapping-lines) (see Wrapping Expressions section; unfortunately, there are no anchors for level 4 headers) as well as by the [original Code Conventions](https://www.oracle.com/java/technologies/javase/codeconventions-indentation.html#272), but the formatting is absolutely in the HTML version.
> 
> At the time, I like your new alignment.
> 
> As far as I know, there are no agreed code style convention that clientlibs follow?

If you accept this change, please, modify the second instance of `throw new IOException` to the same code style.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17010#discussion_r1420730341

From aivanov at openjdk.org  Fri Dec  8 16:32:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Dec 2023 16:32:16 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v2]
In-Reply-To: <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <eeRFk1SjvkiQthu2eNLNmkazrzY8fRv1BRnSzG3jWpk=.1a8aefc9-fe8c-4ace-be4e-f0553b043d4c@github.com>
Message-ID: <auAIIYt0xw2TpvOVJWAEKpBpCvY8eo_usiKSHN3ycXc=.484d24a9-8074-4935-ba65-4fc9f8c89286@github.com>

On Thu, 7 Dec 2023 22:57:52 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
>> 
>> @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - 8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED
>  - Revert "6508941: java.awt.Desktop.open causes VM to crash with video files sporadically"
>    
>    This reverts commit 85269470
>  - Revert "8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED"
>    
>    This reverts commit 4908d9c220950683d3a5010d12ab756eff6b6fa7.

While we're discussing `CoInitialize`, shall we update `initializeCom`

https://github.com/openjdk/jdk/blob/b893a2b2f70346f9d204d1050a0ad32fd98fdd56/src/java.desktop/windows/native/libawt/windows/ShellFolder2.cpp#L297-L300

to use `::CoInitializeEx(NULL, COINIT_APARTMENTTHREADED | COINIT_DISABLE_OLE1DDE)` as it was done in `awt_Desktop.cpp`?

https://github.com/openjdk/jdk/blob/0fd09d383b9921f26d2d609ab330630a4520325a/src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp#L88-L89

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

PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1847483848

From serb at openjdk.org  Fri Dec  8 17:12:29 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 8 Dec 2023 17:12:29 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v3]
In-Reply-To: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
Message-ID: <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>

> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
> 
> @aivanov-jdk please take a look.

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

  Update src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp
  
  date
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17010/files
  - new: https://git.openjdk.org/jdk/pull/17010/files/edcda08c..4c2fac23

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

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

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

From aivanov at openjdk.org  Fri Dec  8 18:33:15 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Dec 2023 18:33:15 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v3]
In-Reply-To: <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
Message-ID: <A15C4Cn9W0Evg45PTEkV6WFAoRp-Nsq-hds6jw-zAoc=.2ea0b5dc-4fac-4ef9-b0fe-af12a457066a@github.com>

On Fri, 8 Dec 2023 17:12:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
>> 
>> @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp
>   
>   date
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17010#pullrequestreview-1772949963

From prr at openjdk.org  Fri Dec  8 18:50:26 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Dec 2023 18:50:26 GMT
Subject: Integrated: 8312307: Obsoleted code in hb-jdk-font.cc
In-Reply-To: <mVwYYfpVdFz6g8imJGHGp_pfNoEaiMiO7JXf88AraLw=.e38b354b-dede-47db-8f2e-be835bc44011@github.com>
References: <mVwYYfpVdFz6g8imJGHGp_pfNoEaiMiO7JXf88AraLw=.e38b354b-dede-47db-8f2e-be835bc44011@github.com>
Message-ID: <c-bowN-SPlihUsozIYG6ljrO2u_DcB57QEtnSFvVtpQ=.6412530d-94a3-4f7b-a984-abfe33bdd3ee@github.com>

On Thu, 7 Dec 2023 18:41:12 GMT, Phil Race <prr at openjdk.org> wrote:

> Clean up some un-used code in the 2D native font code that interfaces to libharfbuzz

This pull request has now been integrated.

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

8312307: Obsoleted code in hb-jdk-font.cc

Reviewed-by: serb

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

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

From prr at openjdk.org  Fri Dec  8 21:58:12 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Dec 2023 21:58:12 GMT
Subject: RFR: 8307246 : Update for sun.print.RasterPrinterJob in
 banded-raster printing loop
In-Reply-To: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
Message-ID: <Oeyfn-G8mmA60fgGG-vZ7XnUb8XCnSdEgdhlNYuB2Rk=.d06bde74-90f1-4f7f-a9c1-4adbec0f9a32@github.com>

On Fri, 8 Dec 2023 05:52:46 GMT, vtstydev <duke at openjdk.org> wrote:

> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper.

This is going to require manual verification.  Likely we'll need to test all possible page orientations too - did you try that ?

The PR title needs to change  to match the bug.
Actually the bug summary is awful, so I'll fix that first then the PR needs to change to match what I've done there.

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

PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1847890143
PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1847891139

From prr at openjdk.org  Fri Dec  8 22:13:15 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Dec 2023 22:13:15 GMT
Subject: RFR: 8321176: [Screencast] make a second attempt on screencast
 failure [v2]
In-Reply-To: <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
 <W9WpAdQm89IICYNIJqZpSVupYkoUY-Ud1oY97xMiXEA=.5344dcb9-52c3-4311-92fb-5271d1ad5967@github.com>
Message-ID: <2WLdBmTf4SEjk1-rHhPccj0aGawqDIxlDyK2a9a8q0E=.742f9c94-7011-439b-bdd4-766a65f772df@github.com>

On Wed, 6 Dec 2023 09:08:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

>> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
>> 
>> The real major change here however is the throw of the RuntimeException which can propagate to public 
>> 
>> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
>> 
>> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
>> 
>> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
>> 
>> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.
>
> Anton Bobrov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8321176: remove RuntimeException and address review comments

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16978#pullrequestreview-1773235252

From duke at openjdk.org  Mon Dec 11 05:35:14 2023
From: duke at openjdk.org (vtstydev)
Date: Mon, 11 Dec 2023 05:35:14 GMT
Subject: RFR: 8307246 : Printing: banded raster path doesn't account for
 device offset values
In-Reply-To: <Oeyfn-G8mmA60fgGG-vZ7XnUb8XCnSdEgdhlNYuB2Rk=.d06bde74-90f1-4f7f-a9c1-4adbec0f9a32@github.com>
References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
 <Oeyfn-G8mmA60fgGG-vZ7XnUb8XCnSdEgdhlNYuB2Rk=.d06bde74-90f1-4f7f-a9c1-4adbec0f9a32@github.com>
Message-ID: <mtbLL5dwBFAKvFSBybKzhmYkUxM0XrtEGTAch6gws5s=.2cf1e157-edcf-4b12-8dc1-a0e7dd9a2654@github.com>

On Fri, 8 Dec 2023 21:54:35 GMT, Phil Race <prr at openjdk.org> wrote:

> This is going to require manual verification. Likely we'll need to test all possible page orientations too - did you try that ?

I printed some documents, that renders with banded-raster printing loop, both orientations on Windows and Linux. They were printed well.

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

PR Comment: https://git.openjdk.org/jdk/pull/17030#issuecomment-1849355391

From duke at openjdk.org  Mon Dec 11 06:05:35 2023
From: duke at openjdk.org (vtstydev)
Date: Mon, 11 Dec 2023 06:05:35 GMT
Subject: RFR: 8307246 : Printing: banded raster path doesn't account for
 device offset values [v2]
In-Reply-To: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
Message-ID: <t8gAV2QqEPKIQdnGF5oqAhWXcYJ175qaGDhPOswZY0Q=.91b77a44-dd80-4bf9-a545-466285525cc8@github.com>

> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper.

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

 - Merge branch 'openjdk:master' into Bugfix
 - More correct way to take in consideration nonzero PHYSICALOFFSETX,PHYSICALOFFSETY of device for banded-raster printing loop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17030/files
  - new: https://git.openjdk.org/jdk/pull/17030/files/347dd4d0..80623ee7

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

  Stats: 12027 lines in 92 files changed: 9705 ins; 2043 del; 279 mod
  Patch: https://git.openjdk.org/jdk/pull/17030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17030/head:pull/17030

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

From duke at openjdk.org  Mon Dec 11 07:04:25 2023
From: duke at openjdk.org (vtstydev)
Date: Mon, 11 Dec 2023 07:04:25 GMT
Subject: RFR: 8307246 : Printing: banded raster path doesn't account for
 device offset values [v3]
In-Reply-To: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
Message-ID: <ddvdGu6NNYN9KeoZqW8Lo7O3B7AeqEYU9zxPLKnuI1Q=.acb4ecf2-83e9-41a5-a7c9-bf4e0d77a83f@github.com>

> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper.

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

  More correct way to take in consideration nonzero PHYSICALOFFSETX,PHYSICALOFFSETY of device for banded-raster printing loop

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

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

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

From duke at openjdk.org  Mon Dec 11 08:32:27 2023
From: duke at openjdk.org (Anton Bobrov)
Date: Mon, 11 Dec 2023 08:32:27 GMT
Subject: Integrated: 8321176: [Screencast] make a second attempt on screencast
 failure
In-Reply-To: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
References: <gfHg_l8ex1LHhlaPvraTMqcov9gzRy47neUFQ_ujz90=.40fa2ae0-a5ed-4117-a8cd-40c9c9cf8b10@github.com>
Message-ID: <K7aAn4XBvhQlYKf2dYx74cFb0bR4RleasID-uLODzMI=.5c00679c-59b6-49b1-aac8-c0db5231a347@github.com>

On Tue, 5 Dec 2023 16:48:55 GMT, Anton Bobrov <duke at openjdk.org> wrote:

> This patch adds re-try logic to libpipewire screencast error handling as discussed in PR #16794 and also brings some additional error handling and thread safety improvements. Specifically around cleanup order where incorrect ordering lead to native memory corruption issues, and lock/unlock accounting that while mostly harmless (with the current libpipewire implementation) did pollute the stderr on jtreg tests, making some tests (expecting clean stderr) to fail.
> 
> The real major change here however is the throw of the RuntimeException which can propagate to public 
> 
> java.awt.Robot. createMultiResolutionScreenCapture, createScreenCapture, getPixelColor methods. I'm not sure the plain RuntimeException is the way to go here so this is just a placeholder of sorts. A separate/specific runtime exception can be created for this BUT *something* needs to be done here as the current implementation fails to convey libpipewire failures to those public API callers and since they have no way of detecting such errors otherwise they have no way of knowing that the data returned by those API is in fact invalid (eg black screens etc). The reason for using an unchecked exception here is driven mainly by the following factors:
> 
> 1) Since those are public API, their contracts can potentially make it difficult to introduce specific additional checked exceptions or return values (as appropriate) as those could potentially break existing API use.
> 
> 2) The libpipewire errors of that kind are rare and usually indicate there is something wrong with the desktop stack eg some fatal configuration or run time error that is normally not supposed to happen and given this patch now goes extra step re-trying on such failures it stands to reason runtime unchecked exception makes sense when that fails as well.
> 
> 3) Creating checked exceptions for such specific native implementation dependent errors and propagating such exceptions thru the call tree does not make much sense as most public API users won't even know how to handle them without knowing native implementation specifics.

This pull request has now been integrated.

Changeset: 92fd490f
Author:    Anton Bobrov <antbob at users.noreply.github.com>
Committer: Alexander Zvegintsev <azvegint at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92fd490f22f690ff7698182658363b7035bcc3bf
Stats:     76 lines in 2 files changed: 52 ins; 16 del; 8 mod

8321176: [Screencast] make a second attempt on screencast failure

Reviewed-by: azvegint, prr

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

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

From duke at openjdk.org  Mon Dec 11 11:41:35 2023
From: duke at openjdk.org (vtstydev)
Date: Mon, 11 Dec 2023 11:41:35 GMT
Subject: RFR: 8307246 : Printing: banded raster path doesn't account for
 device offset values [v4]
In-Reply-To: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
References: <2yu8LstfEaXtLPK7F_EKszTE2HQyi1IZMVa9e4gL6JU=.cc9ea7aa-5a11-45f1-ae70-7d0e0c35b89b@github.com>
Message-ID: <gz4_nWkaIEOM1WdVSncohu-_we1G41MimnJtdwJmBFA=.554e14eb-fc53-45a0-a36c-cb1f682ac1ed@github.com>

> More correct way to take in consideration nonzero PHYSICALOFFSETX, PHYSICALOFFSETY of device for banded-raster printing loop. Only on Windows platform under certain conditions real device prints shifted image on paper.

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

 - Merge branch 'openjdk:master' into Bugfix
 - More correct way to take in consideration nonzero PHYSICALOFFSETX,PHYSICALOFFSETY of device for banded-raster printing loop

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17030/files
  - new: https://git.openjdk.org/jdk/pull/17030/files/347dd4d0..220a283b

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

  Stats: 12207 lines in 105 files changed: 9824 ins; 2063 del; 320 mod
  Patch: https://git.openjdk.org/jdk/pull/17030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17030/head:pull/17030

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

From alexey.ivanov at oracle.com  Mon Dec 11 15:01:10 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Mon, 11 Dec 2023 15:01:10 +0000
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <d64d2551-07d0-de02-5512-1f4aea8c1c72@cjnash.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
 <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
 <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>
 <bd3da4f6-a7c2-b00f-2c7d-f52fdd3b1e4f@cjnash.com>
 <f8a23e32-e1df-4f48-928b-3d05fa2850b3@oracle.com>
 <d64d2551-07d0-de02-5512-1f4aea8c1c72@cjnash.com>
Message-ID: <b1e3f689-bab5-482c-a9de-84d272e943ab@oracle.com>

This has been tracked down to be a regression of JDK-8294427 [1] which 
introduced the dependency on the OpenThemeDataForDpi [2] function from 
Windows API. The function is available since Windows 10 version 1703.

The code review [3] for JDK-8294427 has a discussion [4] on whether 
support for older versions of Windows should be considered.

At that time, it was deemed infeasible [5] to provide this support.

The compatibility problem is now tracked as JDK-8321151 [6].


[1] https://bugs.openjdk.org/browse/JDK-8294427
[2] 
https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi
[3] https://github.com/openjdk/jdk/pull/13701
[4] https://github.com/openjdk/jdk/pull/13701#discussion_r1180829485
[5] https://github.com/openjdk/jdk/pull/13701#discussion_r1227202738
[6] https://bugs.openjdk.org/browse/JDK-8321151

-- 
Regards,
Alexey

On 2023-11-27 14:43, Simon Nash wrote:
> Yes, definitely OK on JDK 21.0.1 and not OK on JDK 22 b16.
>
> Simon
>
> On 25/11/2023 22:57, Philip Race wrote:
>> I'm stumped then. Definitely not a problem with JDK 21u1 ?
>> https://download.java.net/java/GA/jdk21.0.1/415e3f918a1f4062a0074a2794853d0d/12/GPL/openjdk-21.0.1_windows-x64_bin.zip 
>>
>>
>> Try some earlier JDK 22 build too - looks like b16 is the earliest 
>> that is available for download
>> https://download.java.net/java/early_access/jdk22/16/GPL/openjdk-22-ea+16_windows-x64_bin.zip 
>>
>>
>> -phil.
>>
>> On 11/25/23 1:46 PM, Simon Nash wrote:
>>> I tried this with JDK 22 b22 and I got the same result. I will 
>>> investigate further.
>>>
>>> Simon
>>>
>>> On 25/11/2023 18:33, Philip Race wrote:
>>>> Re-read the last line of my previous email and you'll see the answer.
>>>>
>>>> -phil.
>>>>
>>>> On 11/25/23 2:09 AM, Simon Nash wrote:
>>>>> Thanks for confirming that this change was not intentional. I am 
>>>>> using the JDK 22 b24 EA build. When was the Windows compiler and 
>>>>> SDK updated?
>>>>>
>>>>> Simon
>>>>>
>>>>> On 24/11/2023 23:30, Philip Race wrote:
>>>>>> I don't recall anything specific to this. Since you say "current 
>>>>>> EA build", does that imply very recently ?
>>>>>> My guess is that it is fall out from upgrading the Windows 
>>>>>> compiler + SDK and
>>>>>> we are no longer able to load the uxtheme library on Windows 7 
>>>>>> needed for the WindowsL&F.
>>>>>> Note that it has been several years since anyone supported or 
>>>>>> tested Windows 7.
>>>>>> If you can confirm this started with JDK 22 b23 that would pretty 
>>>>>> much confirm the theory.
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>> On 11/24/23 3:08 PM, Simon Nash wrote:
>>>>>>> In the current EA build of JDK 22, selecting WindowsLookAndFeel 
>>>>>>> on Windows 7 shows the same (ugly) UI style as 
>>>>>>> WindowsClassicLookAndFeel.
>>>>>>>
>>>>>>> With JDK 22 on Windows 10 and also with JDK 21 and below on both 
>>>>>>> Windows 7 and Windows 10, this works as expected with different 
>>>>>>> styles for WindowsLookAndFeel and WindowsClassicLookAndFeel.
>>>>>>>
>>>>>>> Is this an intentional change in JDK 22 or a bug? If it is 
>>>>>>> intentional, what was the reason?
>>>>>>>
>>>>>>> Thanks, Simon
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>


From aivanov at openjdk.org  Mon Dec 11 15:06:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Dec 2023 15:06:39 GMT
Subject: RFR: JDK-8294427 - Check boxes and radio buttons have rendering
 issues on Windows in High DPI env [v19]
In-Reply-To: <bK8i3aJN3fCi60m1MRWpZ-BdZtJIYBaHRBz6vVX1FQw=.b83979df-b443-4517-bb89-9f9e112cf4c1@github.com>
References: <0EdwksEferrqonthkTdI393wBfUzH1iQzKCA_H_fLRg=.0ea26507-01d6-48bd-871b-96bc73c4e7e1@github.com>
 <AtakUYhXuWwWNYIh6dmjHSte3dCZc5d3xsFIXhPxdDY=.20b24c11-fe6a-4921-8de9-f7352d3444d4@github.com>
 <jDKWvs3-SqBPy9sgOebDg5ZSPXnIw2qZ2fb3w274yk4=.ba7ad6e1-1a21-425c-9841-60b33ce00faf@github.com>
 <WpxDvVY_Fb61gdRe7HM85PrX5MBrF-h-HyOHsgX_tiI=.32a6e113-864f-465c-9240-3a38f6801ef1@github.com>
 <k9U4bWSkv_j3-CcQGE6KCUgaQyG4MSwgxHYYh8Ofwxk=.3ef596ca-d4e7-4274-af5c-ca6b472a9a62@github.com>
 <aQUac6JBuCL61qi08F2fh7CPXj-J8pEz6pyCwKmtF4I=.744adc9e-ceea-4cb1-a332-da23415430f4@github.com>
 <bK8i3aJN3fCi60m1MRWpZ-BdZtJIYBaHRBz6vVX1FQw=.b83979df-b443-4517-bb89-9f9e112cf4c1@github.com>
Message-ID: <AWNpPj7UJCOqWdK-8eUa0H-ALFIHlze0hLZI0OPM0sQ=.f6212bb1-59ad-44ae-b7bf-e13d64e17e72@github.com>

On Mon, 12 Jun 2023 20:23:00 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> > It may be useful to be able to run Java on previous versions though, yet it's not a priority.
>>> 
>>> Then probably it is better to add a fallback since that method was added to the win 10 after GA, and it does not exist in the early version.
>> 
>> But the earlier versions of Windows 10 are already unsupported, including the one where the `OpenThemeDataForDpi` function was added.
>> 
>> If required, the fallback could be implemented under a new bug. ~~Anyway, I don't have a strong opinion on this matter.~~
>
> I think it's *unfeasible* to provide the fallback to keep the code simpler.
> 
> If `OpenThemeDataForDpi` isn't available, we cannot get per-DPI images. Then we have to fallback to using the DPI of the main display and scale up / down all the returned values and images.

> If required, the fallback could be implemented under a new bug.

The compatibility problem was reported on the [client-libs-dev mailing list](https://mail.openjdk.org/pipermail/client-libs-dev/2023-November/016360.html). It is tracked as [JDK-8321151](https://bugs.openjdk.org/browse/JDK-8321151).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13701#discussion_r1422613098

From serb at openjdk.org  Mon Dec 11 18:39:35 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 11 Dec 2023 18:39:35 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v3]
In-Reply-To: <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
Message-ID: <TCIzaLeI5RcL6MxXC2B22jN4c8KhXYet7QHN3Say4JY=.02ef4a86-ceee-49a8-87ac-542bae3052a8@github.com>

On Fri, 8 Dec 2023 17:12:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
>> 
>> @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp
>   
>   date
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

>The confusion could come from https://github.com/openjdk/jdk/pull/14898 where https://github.com/openjdk/jdk/pull/14898#issuecomment-1748967705 us from calling DirectSound API which supports both MTA and STA.

Would like to clarify difference between this and that patch: this bug shows that some api does not support MTA mode, and intentionally requests the STA - so our code was broken by some external call -> enable COM+MTA.
At the same time the [patch](https://github.com/openjdk/jdk/pull/14898) may change the current mode of the thread from STA to MTA and that seems could break all code executed after?

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

PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1850662854

From aivanov at openjdk.org  Mon Dec 11 19:27:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Dec 2023 19:27:35 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v3]
In-Reply-To: <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
Message-ID: <E--6UHICP0sBihvkdIbFvZlJeICS1pZz_tRnAKPo1QA=.1ca94b24-d8de-4a32-82f8-3e0bef544c5d@github.com>

On Fri, 8 Dec 2023 17:12:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
>> 
>> @aivanov-jdk please take a look.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.desktop/windows/native/libawt/windows/awt_Desktop.cpp
>   
>   date
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

> > The confusion could come from #14898 where [#14898 (comment)](https://github.com/openjdk/jdk/pull/14898#issuecomment-1748967705) us from calling DirectSound API which supports both MTA and STA.
> 
> Would like to clarify difference between this and that patch: this bug shows that some api does not support MTA mode, and intentionally requests the STA - so our code was broken by some external call -> enable COM+MTA.
>
> At the same time the [patch](https://github.com/openjdk/jdk/pull/14898) may change the current mode of the thread from STA to MTA and that seems could break all code executed after?

How come? It can't change: once COM is initialised on a thread, its threading model cannot be changed. This is what `RPC_E_CHANGED_MODE` error code conveys, in other words you request initialising COM in a threading model that's different the model COM has been initialised previously.

The code in #14898 always initialises COM in MTA. If COM is initialised in STA, the thread and COM remains in STA. The only difference is that it is still *valid* to call the DirectSound API because the API supports both MTA and STA modes.

This case corresponds to option 3 in [this comment](https://github.com/openjdk/jdk/pull/14898#issuecomment-1748967705).

In other words the workflow in case 3 of JDK-8301846 / PR 14898:


// some app code
COM -> STA = S_OK
// more code
AudioSystem.getMixerInfo():
    COM -> MTA = RPC_E_CHANGED_MODE
    // threading model still STA
    DirectSoundEnumerateW / DirectSoundCaptureEnumerateW
    skip ::CoUninitialize()
// thread continues with COM in STA


(I was even inclined to use [the same approach](https://github.com/openjdk/jdk/pull/14898#discussion_r1276539431) with a worker thread which initialises COM to avoid dealing with `RPC_E_CHANGED_MODE`. It was only after I had received [clarification from Microsoft](https://github.com/openjdk/jdk/pull/14898#issuecomment-1721687912) that I changed my opinion because (a) Initialising and uninitialising COM aren't heavy; (b) DirectSound APIs support both MTA and STA.)

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

PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1850737151

From serb at openjdk.org  Mon Dec 11 20:41:14 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 11 Dec 2023 20:41:14 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v3]
In-Reply-To: <E--6UHICP0sBihvkdIbFvZlJeICS1pZz_tRnAKPo1QA=.1ca94b24-d8de-4a32-82f8-3e0bef544c5d@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
 <E--6UHICP0sBihvkdIbFvZlJeICS1pZz_tRnAKPo1QA=.1ca94b24-d8de-4a32-82f8-3e0bef544c5d@github.com>
Message-ID: <0w0nSTvM45fXO6meVDDO7dAI8AQ8ZurlxcGndx2hMPo=.3c74f08c-02df-444b-8638-de783ba40e32@github.com>

On Mon, 11 Dec 2023 19:24:34 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>How come? It can't change: once COM is initialised on a thread, its threading model cannot be changed. This is what RPC_E_CHANGED_MODE error code conveys, in other words you request initialising COM in a threading model that's different the model COM has been initialised previously.

Hmm for some reason after reading this doc I decided that the transition from STA to MTA is possible:
https://learn.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-coinitializeex
>RPC_E_CHANGED_MODE:
>A previous call to [CoInitializeEx](https://learn.microsoft.com/en-us/windows/desktop/api/combaseapi/nf-combaseapi-coinitializeex) specified the concurrency model for this thread as multithread apartment (MTA). This could also indicate that a change from neutral-threaded apartment to single-threaded apartment has occurred.

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

PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1850851946

From aivanov at openjdk.org  Mon Dec 11 21:04:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Dec 2023 21:04:33 GMT
Subject: RFR: 8270269: Desktop.browse method fails if earlier CoInitialize
 call as COINIT_MULTITHREADED [v3]
In-Reply-To: <0w0nSTvM45fXO6meVDDO7dAI8AQ8ZurlxcGndx2hMPo=.3c74f08c-02df-444b-8638-de783ba40e32@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
 <6kleKtEG40OwclwIOss4ttDnXwdGsTicuIfIqTpFDgw=.adcd6f38-aed2-4686-b178-d724ddff5710@github.com>
 <E--6UHICP0sBihvkdIbFvZlJeICS1pZz_tRnAKPo1QA=.1ca94b24-d8de-4a32-82f8-3e0bef544c5d@github.com>
 <0w0nSTvM45fXO6meVDDO7dAI8AQ8ZurlxcGndx2hMPo=.3c74f08c-02df-444b-8638-de783ba40e32@github.com>
Message-ID: <MiWPgS1148AXy7kWNom-9Jy3ern14Z6lXLmASkAgYYM=.18e50f11-6a14-41cb-abaa-90523f65cf80@github.com>

On Mon, 11 Dec 2023 20:38:46 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> A previous call to [CoInitializeEx](https://learn.microsoft.com/en-us/windows/desktop/api/combaseapi/nf-combaseapi-coinitializeex) specified the concurrency model for this thread as multithread apartment (MTA). This could also indicate that a change from neutral-threaded apartment to single-threaded apartment has occurred.

It's confusing, and [Neutral Apartments](https://learn.microsoft.com/en-us/windows/win32/cossdk/neutral-apartments) does not clarify anything. [The Apartment and the COM Threading Architecture](https://learn.microsoft.com/en-us/windows/win32/com/processes--threads--and-apartments#the-apartment-and-the-com-threading-architecture) section in ?Processes, Threads, and Apartments? article doesn't mention *neutral* at all.

At the same time, I am sure the transition from STA to MTA or from MTA to STA is not possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/17010#issuecomment-1850881527

From tr at openjdk.org  Tue Dec 12 05:02:54 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 12 Dec 2023 05:02:54 GMT
Subject: RFR: 8259550: The content of the print out displayed incomplete with
 the NimbusLAF
Message-ID: <Cjnogsfj0L3XMy68YLrKijalcbIryZy2qNdYycvCqhw=.97b2e41a-b8e0-4969-881b-ed12d0ad63c1@github.com>

The issue is w.r.t to way that Synth prints the table. In Synth, the printing of Table happens column wise by painting blocks of columns which is due to the fact that Graphics used which is `ProxyGrpahics2D` (which get selected in `RasterPrinterJob `class, otherwise it would be `WPathGraphics` for other Look and feel).  Since the printing happens in block wise and the columns where the x position is greater than the `table.bounds` doesn't gets painted because of the intersection check condition `!bounds.intersects(clip)`. Hence only droplines are painted instead of cells and gridlines.  I couldn't find any reason for adding the intersection check here and when removed it didn't cause any regression too, rather it solves the issue and actually made sense too. In other Look and Feel its not required to apply the fix (in `BasicTableUI `class) because its not affecting anything yet since the painting happens for whole table. Hence proposing the fix for only SynthTableUI class.
([PrintManualTest_FitWidthMultiple.java](https://github.com/openjdk/jdk/blob/master/test/jdk/javax/swing/JTable/PrintManualTest_FitWidthMultiple.java)) test is been used for testing.

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

Commit messages:
 - Fix

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

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

From alexsch at openjdk.org  Tue Dec 12 10:27:24 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 12 Dec 2023 10:27:24 GMT
Subject: RFR: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
Message-ID: <3MuVjX76A-vNZVN14DAxTgymzhMYJIxNCbg-3S8wNwA=.bb719c43-beed-416e-92f5-e9b2def9f7ad@github.com>

On Thu, 12 Oct 2023 15:51:28 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
> The same is true for `CustomMediaTray` class.
> 
> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
> 
> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.

What should be done with this pull request as the https://github.com/openjdk/jdk/pull/16752 `8320365: IPPPrintService.getAttributes() causes blanket re-initialisation` has been integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/16167#issuecomment-1851752946

From alexsch at openjdk.org  Tue Dec 12 13:04:02 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Tue, 12 Dec 2023 13:04:02 GMT
Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute
 extension [v4]
In-Reply-To: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
References: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
Message-ID: <ChHHI40ryJej-MQA5Fuqun3I0yUY6vGH6lCPfpPocmc=.82a8bb14-7239-4029-8de8-a895780a87c6@github.com>

> 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 with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge master
 - Add empty lines between OutputBin constants
 - Add Override annotation to OutputBin and CustomOutputBin methods
 - Update OutputBin IPP Compatibility description
 - Remove System.out.printf(...)
 - 8318023: Implement IPP output-bin attribute extension on macOS

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

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

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

From tr at openjdk.org  Tue Dec 12 13:10:49 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 12 Dec 2023 13:10:49 GMT
Subject: RFR: 8187759: Background not refreshed when painting over a
 transparent JFrame
Message-ID: <A-0sdTMigR7r9t_uzMLPHolzp3w2I5u-P1DXbCLV1X4=.8b66398a-e88d-4fc2-848f-a02dac236ccc@github.com>

This is happening in linux where `BuffereStrategyPaintManager` is used to paint to offscreen. Here `bsg` bufferStrategy SunGraphics2D is used to paint to offscreen where the background is not refreshed, which does only clipping and then paints to offscreen. In order to handle the screen updated/clear the buffer, `setBackground` to component background color and `clearRect` against the clip area is used which solves the issue without causing any regression. 
CI is green for the fix and manual test is provided.

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

Commit messages:
 - Linux tag added
 - fix + manual test

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

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

From serb at openjdk.org  Tue Dec 12 18:33:39 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 12 Dec 2023 18:33:39 GMT
Subject: Integrated: 8270269: Desktop.browse method fails if earlier
 CoInitialize call as COINIT_MULTITHREADED
In-Reply-To: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
References: <soWUkMQg0jQeXERvEfDXzVAduTELSBpdRaJoIw3IhMU=.b0587798-f0dc-4ffb-8d5f-f3741ca114e6@github.com>
Message-ID: <x2wj7t9qrA2FYhU-Ei0AqaqFx8hAC9f3zMo3pbTHN6o=.69a56219-0a75-492a-8c6a-584d869b1b0b@github.com>

On Thu, 7 Dec 2023 03:03:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The fix for a regression caused by the https://bugs.openjdk.org/browse/JDK-6508941. it does not take into account RPC_E_CHANGED_MODE when COM was already initialized using COINIT_MULTITHREADED mode.
> 
> @aivanov-jdk please take a look.

This pull request has now been integrated.

Changeset: b25ed57b
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b25ed57b764fc485e4e8ca4118ffb1cc70fdfe7f
Stats:     25 lines in 2 files changed: 4 ins; 10 del; 11 mod

8270269: Desktop.browse method fails if earlier CoInitialize call as COINIT_MULTITHREADED

Reviewed-by: aivanov

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

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

From alexsch at openjdk.org  Wed Dec 13 15:58:03 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Wed, 13 Dec 2023 15:58:03 GMT
Subject: RFR: 8314070: javax.print: Support IPP output-bin attribute
 extension [v5]
In-Reply-To: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
References: <NXwdDAcdcm_s9B3HbmPyt1RgXBCLXm4TvIPudLvPEFc=.90579103-04b2-4813-96ee-37844ef3eb83@github.com>
Message-ID: <1IZMIOuXSec2PYnGvp5rTDBFDatCsAh1lcZOhwTR2oM=.058bb44a-b228-41af-99fc-de0f602370fb@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16166/files
  - new: https://git.openjdk.org/jdk/pull/16166/files/25e3ffa1..45f953cf

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

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

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

From alexsch at openjdk.org  Wed Dec 13 16:07:44 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Wed, 13 Dec 2023 16:07:44 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: <mMaO8mcFqQi3r_YVWGXoYH3rlOSZlNF-mNIXeVXpabg=.26a61f05-1812-4843-a3d1-b94395dc324a@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

The common print dialog is updated to show supported output bins.

- `OutputPanel` is added to the `ServiceDialog` to show list of supported output bins in the ComboBox.
- `order.output` and `label.outputbins` properties are added to `serviceui.properties`.
- `CPrinterJob.nsPrintInfoToJavaPrinterJob()` method is updated to add the selected output bin from the native print dialog to the printer job attributes.
- `OutputBinAttributePrintDialogTest` manual test that checks only printing to the first and the last supported output bins with common and native print dialog is added.
 
Common print dialog with the fix which shows list of supported output bins on macOS:
<img src="https://github.com/openjdk/jdk/assets/23520046/ce66ab7d-9783-4e4f-93b9-207bad836541" width="50%">

The same dialog with disabled output trays when the list of output bins is empty:
<img src="https://github.com/openjdk/jdk/assets/23520046/be50f92b-e346-4a42-9f52-bf4089e30e5f" width="50%">

The same dialog without the fix:
<img src="https://github.com/openjdk/jdk/assets/23520046/904d60b3-d7a1-4235-a415-317b7dcba300" width="50%">

There is the comment on `social.msdn.microsoft.com` forum that wingdi does not support setting output bin attribute programmatically: 

"'Output tray" is a printer-specific property (note that you will only see such an option
in the printing interface for certain printers).  There is no way to programmatically set 
an output tray, since there is no generic way of doing it via .NET (or even Win32 
via the DEVMODE structure).  The only way to set it is to allow the user
to choose it via the provided printer dialog for the few printers that provide this capability
(just as you must do via IE or Word).

It is sometimes possible to do this programmatically (without the dialog) for a specific
printer if you know exactly how that printer driver implements the change...but that
is unsupported  except possibly from the printer manufacturer.

https://social.msdn.microsoft.com/Forums/en-US/b15eda2f-5353-41fc-b935-078ed0960aee/printing-into-a-specific-output-bintray-net

That is why `OutputPanel` is excluded from the `ServiceDialog` on Windows.

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

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

From duke at openjdk.org  Thu Dec 14 08:13:58 2023
From: duke at openjdk.org (duke)
Date: Thu, 14 Dec 2023 08:13:58 GMT
Subject: Withdrawn: 6681958: Maximization state of JInternalFrames is corrupted
 by WindowsDesktopManager
In-Reply-To: <5OwD7o3mUCM5PP-oI9VuYyevvuLQaggzfwnkvz8OtGw=.d3d4634a-769f-4a0d-938a-3b6828269952@github.com>
References: <5OwD7o3mUCM5PP-oI9VuYyevvuLQaggzfwnkvz8OtGw=.d3d4634a-769f-4a0d-938a-3b6828269952@github.com>
Message-ID: <x1sW2T5Bo69LrJ7V0WoWeyUg9aY2iKro_X2Ygkl9vg0=.95e7fa1b-3a8b-492a-bccc-f4943da21a70@github.com>

On Mon, 9 Oct 2023 05:17:58 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Issue is if one internal frame is open and maximized and another internal frame is created which is initialized with setMaximum(true) then after opening the second internal frame both internal frames are non-maximized
> It can also be seen with SwingSet2 JInternalFrameDemo in WIndowsLookAndFeel i.e. when Frame 0 is maximised, and then Frame1 is maximised and then minimised, Frame0 should remain maximised but it is now unmaximised
> 
> Issues seen with JInternalFrame in WindowsLookAndFeel are
> - Frame 0 maximised
>  - Frame 4 maximised, when minimised, Frame0 is seen to be restored to normal size with Frame4 minimised
>  - Frame 0 is again maximised
>  - Frame 4 maximised from minimised, instead of maximising, it restores both Frame0 and Frame4
> 
> The fix makes sure the maximised internal frame remains maximised when the 2nd internal frame is maximised
> This code seems to be added for [JDK-5036083](https://bugs.openjdk.org/browse/JDK-5036083) which expects 
> `When a frame is maximized and then minimized, the next frame should NOT be maximized.`
> 
> It still honours that fix as the  test mentioned in JDK-5036083 works as expected as mentioned above
> 
> Also it is mentioned 
> https://github.com/openjdk/jdk/blob/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d/src/java.desktop/windows/classes/com/sun/java/swing/plaf/windows/WindowsDesktopManager.java#L69-L70
> 
> It can be seen it is still honored. In SwingSet2 JInternalFrameDemo in WindowsL&F, if Frame0 is maximised and then Frame1 is activated/selected, it becomes maximised
> Also, it doesn't cause any regression with our existing closed/open tests.

This pull request has been closed without being integrated.

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

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

From psadhukhan at openjdk.org  Thu Dec 14 08:39:48 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 14 Dec 2023 08:39:48 GMT
Subject: Withdrawn: 8320057: [macos14]
 javax/swing/JToolTip/4846413/bug4846413.java: Tooltip has not been found!
In-Reply-To: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
References: <gcfArz9BpMGsfe6lVNkqRL8Q_rJeF2BzFwCA8n6fcDU=.688945ab-f129-40bc-9522-7b76892f026c@github.com>
Message-ID: <ZWNd7Xi41TaHAafERiDrpPoqSpIlsJpxYlikAkI58V4=.bda15044-f3d3-462f-bdbc-8fa58936929a@github.com>

On Wed, 22 Nov 2023 08:46:32 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> Test failing on macos14 citing "ToolTip not found"...Investigation shows that the mouse is not moved when invoked 1st time to desired location on screen causing tooltip to not show...However, subsequent runs of the same test without any change causes it to pass every time.
> Workaround is proposed to check if running on 14.x, then invoke a dummy mouse movement to same location which causes the test to pass for several iterations in macos14 environment.

This pull request has been closed without being integrated.

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

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

From tr at openjdk.org  Thu Dec 14 11:08:50 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 14 Dec 2023 11:08:50 GMT
Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test
 Instructions.
Message-ID: <aPXGtFOu01x-HnIwlm9SU16yEd_JWGuStIkkm-r99hg=.e67e0f12-4a5f-4a81-8e2d-4484c3f6bc7d@github.com>

By default `JTable.setColumnSelectionAllowed()` is set to false in `DefaultTableColumnModel` class and `JTable.setRowSelectionAllowed()` is set to true in `JTable` class. In order to navigate table as per [JDK-4112270](https://bugs.openjdk.org/browse/JDK-4112270), column selection to be made true.

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

Commit messages:
 - fix

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

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

From prr at openjdk.org  Thu Dec 14 21:34:41 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Dec 2023 21:34:41 GMT
Subject: RFR: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
Message-ID: <8cVVyZNIio1Qpm5FkkUIDwoziyrtHKUGiqYu7grqT9Q=.51ace861-5a2c-4c7e-8479-14424f5be443@github.com>

On Thu, 12 Oct 2023 15:51:28 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
> The same is true for `CustomMediaTray` class.
> 
> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
> 
> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.

I thought your fix is still useful, even if the problem isn't visible any more.
That's why I wrote 
"Right now, I'm inclined to suggest you push the fix you have (modulo my existing comments that need to be addressed)"

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

PR Comment: https://git.openjdk.org/jdk/pull/16167#issuecomment-1856656710

From aivanov at openjdk.org  Fri Dec 15 15:21:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 15 Dec 2023 15:21:44 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v7]
In-Reply-To: <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com>
Message-ID: <eB5hOMam317JwcYoDgmmab4AkYBKQstEiTAkJuT3vK0=.b9690a95-b8f3-425e-95f6-e73023ae514f@github.com>

On Tue, 21 Nov 2023 08:40:40 GMT, songpv-imt <duke at openjdk.org> wrote:

>> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
>> 
>> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)
>
> songpv-imt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterJVMGetDropSuccessTest.java
>   Instead of using SYNC_LOCK to synchronize accessing the listener's fields, for better code transparency, we have placed the code that accesses the listener's fields from the main thread into the AWT Event Queue.

test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 273:

> 271:             robot.setAutoWaitForIdle(true);
> 272:             robot.mouseMove(sourcePoint.x, sourcePoint.y);
> 273:             Thread.sleep(50);

Suggestion:

            robot.delay(50);

Using `Robot.delay` is more common in tests, and it doesn't throw `InterruptedException`.

test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 287:

> 285:             }
> 286: 
> 287:             EventQueue.invokeAndWait(()-> {

Suggestion:

            EventQueue.invokeAndWait(() -> {

Added a space to follow the common code style.

test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 335:

> 333:         }
> 334:     } // run()
> 335: } // class child

Please keep one blank line in the end of the files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1428090457
PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1428093169
PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1428092599

From serb at openjdk.org  Fri Dec 15 19:44:39 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Dec 2023 19:44:39 GMT
Subject: RFR: 8187759: Background not refreshed when painting over a
 transparent JFrame
In-Reply-To: <A-0sdTMigR7r9t_uzMLPHolzp3w2I5u-P1DXbCLV1X4=.8b66398a-e88d-4fc2-848f-a02dac236ccc@github.com>
References: <A-0sdTMigR7r9t_uzMLPHolzp3w2I5u-P1DXbCLV1X4=.8b66398a-e88d-4fc2-848f-a02dac236ccc@github.com>
Message-ID: <p6K402lvUV56faEaufmosTRLo8-6DTIDOu6yblDaJ64=.b1bd614c-2600-46c3-b785-dac5f2270fe8@github.com>

On Tue, 12 Dec 2023 13:04:26 GMT, Tejesh R <tr at openjdk.org> wrote:

>This is happening in linux
Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?

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

PR Comment: https://git.openjdk.org/jdk/pull/17081#issuecomment-1858401386

From simon at cjnash.com  Fri Dec 15 22:04:30 2023
From: simon at cjnash.com (Simon Nash)
Date: Fri, 15 Dec 2023 22:04:30 +0000
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <b1e3f689-bab5-482c-a9de-84d272e943ab@oracle.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
 <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
 <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>
 <bd3da4f6-a7c2-b00f-2c7d-f52fdd3b1e4f@cjnash.com>
 <f8a23e32-e1df-4f48-928b-3d05fa2850b3@oracle.com>
 <d64d2551-07d0-de02-5512-1f4aea8c1c72@cjnash.com>
 <b1e3f689-bab5-482c-a9de-84d272e943ab@oracle.com>
Message-ID: <c4cd0602-c68a-c6cd-a5f7-e548562d2d00@cjnash.com>

Thanks for looking into this. I'm commenting here because I don't think I am able to to add comments in JDK-8321151.

if exact scaling is difficult, any reasonable approximation would be better than falling back to the Windows NT LookAndFeel, as Phil Race has commented in 
JDK-8321151.

Simon

On 11/12/2023 15:01, Aleksei Ivanov wrote:
> This has been tracked down to be a regression of JDK-8294427 [1] which introduced the dependency on the OpenThemeDataForDpi [2] function from Windows API. The 
> function is available since Windows 10 version 1703.
>
> The code review [3] for JDK-8294427 has a discussion [4] on whether support for older versions of Windows should be considered.
>
> At that time, it was deemed infeasible [5] to provide this support.
>
> The compatibility problem is now tracked as JDK-8321151 [6].
>
>
> [1] https://bugs.openjdk.org/browse/JDK-8294427
> [2] https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi
> [3] https://github.com/openjdk/jdk/pull/13701
> [4] https://github.com/openjdk/jdk/pull/13701#discussion_r1180829485
> [5] https://github.com/openjdk/jdk/pull/13701#discussion_r1227202738
> [6] https://bugs.openjdk.org/browse/JDK-8321151
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231215/39cf9478/attachment.htm>

From duke at openjdk.org  Mon Dec 18 03:25:00 2023
From: duke at openjdk.org (songpv-imt)
Date: Mon, 18 Dec 2023 03:25:00 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v8]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: <qKdBZVnAIGo3kPvVNGpz_pen36TWI6m_nP0DejiRr5o=.c2bf6101-f623-4a2f-9b84-6548757dc996@github.com>

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

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

  Update InterJVMGetDropSuccessTest.java
  - Replace Thread.sleep by robot.delay
  - Fix the code's formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16396/files
  - new: https://git.openjdk.org/jdk/pull/16396/files/9a9c3112..2521a8e0

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

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

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

From duke at openjdk.org  Mon Dec 18 03:25:03 2023
From: duke at openjdk.org (songpv-imt)
Date: Mon, 18 Dec 2023 03:25:03 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v7]
In-Reply-To: <eB5hOMam317JwcYoDgmmab4AkYBKQstEiTAkJuT3vK0=.b9690a95-b8f3-425e-95f6-e73023ae514f@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <4_Xhk9SMIvvOthojgfccDt2kRA6DXR5xA7TDG4ujKCU=.465bafb2-7a81-4b72-8413-8216d11d6b07@github.com>
 <eB5hOMam317JwcYoDgmmab4AkYBKQstEiTAkJuT3vK0=.b9690a95-b8f3-425e-95f6-e73023ae514f@github.com>
Message-ID: <sPVmKb-NxeMbIqiGDYqBWCM_dWvPWKfdxUnmfMCIxQ0=.1bf783db-9c38-407a-a861-78f20158eed2@github.com>

On Fri, 15 Dec 2023 15:16:32 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> songpv-imt has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update InterJVMGetDropSuccessTest.java
>>   Instead of using SYNC_LOCK to synchronize accessing the listener's fields, for better code transparency, we have placed the code that accesses the listener's fields from the main thread into the AWT Event Queue.
>
> test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 273:
> 
>> 271:             robot.setAutoWaitForIdle(true);
>> 272:             robot.mouseMove(sourcePoint.x, sourcePoint.y);
>> 273:             Thread.sleep(50);
> 
> Suggestion:
> 
>             robot.delay(50);
> 
> Using `Robot.delay` is more common in tests, and it doesn't throw `InterruptedException`.

Thank you for your suggestions. The changes have been incorporated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1429444342

From tr at openjdk.org  Mon Dec 18 05:05:40 2023
From: tr at openjdk.org (Tejesh R)
Date: Mon, 18 Dec 2023 05:05:40 GMT
Subject: RFR: 8187759: Background not refreshed when painting over a
 transparent JFrame
In-Reply-To: <p6K402lvUV56faEaufmosTRLo8-6DTIDOu6yblDaJ64=.b1bd614c-2600-46c3-b785-dac5f2270fe8@github.com>
References: <A-0sdTMigR7r9t_uzMLPHolzp3w2I5u-P1DXbCLV1X4=.8b66398a-e88d-4fc2-848f-a02dac236ccc@github.com>
 <p6K402lvUV56faEaufmosTRLo8-6DTIDOu6yblDaJ64=.b1bd614c-2600-46c3-b785-dac5f2270fe8@github.com>
Message-ID: <yHOWBR1bDoS0NtrozRxKdy3KDxD3OtMjplWW_mlsz48=.7317de1f-8b8b-4cef-aa3d-7e2f69f4dbc8@github.com>

On Fri, 15 Dec 2023 19:41:53 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> > This is happening in linux
> > Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?

Yes, This is happening only in linux. The paintToOffScreen is done by BufferStrategyPaintManager rather than RepaintManager (which is the case in macOS and Windows).

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

PR Comment: https://git.openjdk.org/jdk/pull/17081#issuecomment-1859559961

From alexsch at openjdk.org  Mon Dec 18 12:14:53 2023
From: alexsch at openjdk.org (Alexander Scherbatiy)
Date: Mon, 18 Dec 2023 12:14:53 GMT
Subject: Integrated: 7001133: OutOfMemoryError by CustomMediaSizeName
 implementation
In-Reply-To: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
References: <7njRJbIWTvk2w-2CLDI0ZSlilGJ_6-5MFsTwWBUdjSo=.47858f3c-0d7e-4318-8c29-793293a6fac5@github.com>
Message-ID: <oYqqL9Ul85kg9oiuU65Qh2HUaeHQuPa2xKhdjGasJ3A=.8d2c3c82-3628-4119-adc7-f3f4b9047371@github.com>

On Thu, 12 Oct 2023 15:51:28 GMT, Alexander Scherbatiy <alexsch at openjdk.org> wrote:

> Each time `CUPSPrinter.initMedia()` method is called it creates new `CustomMediaSizeName` objects which are all collected in static `CustomMediaSizeName.customEnumTable` field. A lot of created duplicated `CustomMediaSizeName` objects wastes java heap space and can lead to `PrintService.getAttributes()` method call time degradation especially when a lot of different printers are installed in the operation system.
> The same is true for `CustomMediaTray` class.
> 
> The fix adds a `create()` method and a hash map which allows to reuse created  `CustomMediaSizeName/CustomMediaTray` objects. It seems that adding `equals(...)` method to `CustomMediaSizeName/CustomMediaTray` classes violates parent `Media` class contract which compares media objects only by `value` fields. The fix adds inner classes which are used as a key in corresponding hash maps.
> 
> `test/jdk/javax/print` and `test/jdk/java/awt/print` automated tests were run to check the fix on Linux and macOS.

This pull request has now been integrated.

Changeset: 10335f60
Author:    Alexander Scherbatiy <alexsch at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/10335f60f923aa4f315e64acb2bfd7bb06d47a1b
Stats:     173 lines in 5 files changed: 153 ins; 13 del; 7 mod

7001133: OutOfMemoryError by CustomMediaSizeName implementation

Reviewed-by: psadhukhan

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

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

From aivanov at openjdk.org  Mon Dec 18 16:17:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 18 Dec 2023 16:17:41 GMT
Subject: RFR: 8187759: Background not refreshed when painting over a
 transparent JFrame
In-Reply-To: <yHOWBR1bDoS0NtrozRxKdy3KDxD3OtMjplWW_mlsz48=.7317de1f-8b8b-4cef-aa3d-7e2f69f4dbc8@github.com>
References: <A-0sdTMigR7r9t_uzMLPHolzp3w2I5u-P1DXbCLV1X4=.8b66398a-e88d-4fc2-848f-a02dac236ccc@github.com>
 <p6K402lvUV56faEaufmosTRLo8-6DTIDOu6yblDaJ64=.b1bd614c-2600-46c3-b785-dac5f2270fe8@github.com>
 <yHOWBR1bDoS0NtrozRxKdy3KDxD3OtMjplWW_mlsz48=.7317de1f-8b8b-4cef-aa3d-7e2f69f4dbc8@github.com>
Message-ID: <aNVOH_vfzkXHlXEJ88tJf_d0YfheYj-5fazAldHhrfc=.0ae770d2-9c64-43d6-b565-05d710e01051@github.com>

On Mon, 18 Dec 2023 05:02:42 GMT, Tejesh R <tr at openjdk.org> wrote:

> > > This is happening in linux
> > > Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?
> 
> Yes, This is happening only in linux. The paintToOffScreen is done by BufferStrategyPaintManager rather than RepaintManager (which is the case in macOS and Windows).

Renjith @Renjithkannath worked on a similar bug, [JDK-8256639](https://bugs.openjdk.org/browse/JDK-8256639): _Test `javax/swing/JPopupMenu/7160604/bug7160604.java` fails on Ubuntu_, and he reproduced the problem on macOS too, yet you have to make popups lightweight, they're heavyweight on macOS by default.

He tracked it down to the same root cause. His suggested fix was very similar to the one that @TejeshR13 proposes here. I wasn't convinced at that time that it was the best fix but I hadn't had time to look into it further.

Neither have I looked at this code review thoroughly yet.

Unfortunately, JDK-8256639 cannot be opened because it contains confidential information in its description.

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

PR Comment: https://git.openjdk.org/jdk/pull/17081#issuecomment-1860936199

From honkar at openjdk.org  Tue Dec 19 01:18:50 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 19 Dec 2023 01:18:50 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v8]
In-Reply-To: <qKdBZVnAIGo3kPvVNGpz_pen36TWI6m_nP0DejiRr5o=.c2bf6101-f623-4a2f-9b84-6548757dc996@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
 <qKdBZVnAIGo3kPvVNGpz_pen36TWI6m_nP0DejiRr5o=.c2bf6101-f623-4a2f-9b84-6548757dc996@github.com>
Message-ID: <QKhbYx8v-eMlB3Zb7tFDpzw1pwefQqEZvK5uMt523Do=.50698e36-a4b3-4260-a626-bfdaef7b0a7c@github.com>

On Mon, 18 Dec 2023 03:25:00 GMT, songpv-imt <duke at openjdk.org> wrote:

>> The root cause of the bug is because mousePress() method is invoked before mouseMove() event is completely processed causing the drag & drop behavior not being able to be recognized properly. This in turn makes the method dragSourceListener.isDropFinished() returns false and fail the test. To fix this, setAutoWaitForIdle(true) and Thread.Sleep is called to make sure the mouseMove() event is processed completely before moving to execute the mousePress() method.
>> 
>> JBS issue: [JDK-8317287](https://bugs.openjdk.org/browse/JDK-8317287)
>
> songpv-imt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update InterJVMGetDropSuccessTest.java
>   - Replace Thread.sleep by robot.delay
>   - Fix the code's formatting

Both the original test and updated test in this PR pass on the latest macOS version 14.2. Since this is a test stabilization fix I would like to suggest a change to JBS title to reflect it since the current one might be misleading.

test/jdk/java/awt/dnd/InterJVMGetDropSuccessTest/InterJVMGetDropSuccessTest.java line 230:

> 228: 
> 229:     private boolean success1 = false;
> 230:     private boolean success2 = false;

These boolean vars need to be volatile since they are accessed on two different threads.

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

Changes requested by honkar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16396#pullrequestreview-1787940514
PR Review Comment: https://git.openjdk.org/jdk/pull/16396#discussion_r1430800164

From duke at openjdk.org  Tue Dec 19 02:09:08 2023
From: duke at openjdk.org (songpv-imt)
Date: Tue, 19 Dec 2023 02:09:08 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v9]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: <2N2LTQWDWIXcKiHYD-adxUpwq49-GN-YwE88LhB-LrU=.543ae6c1-624d-481b-9e70-3df93b5c3d79@github.com>

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

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

  Update InterJVMGetDropSuccessTest.java
  - Update success1 and success2 to volatile

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16396/files
  - new: https://git.openjdk.org/jdk/pull/16396/files/2521a8e0..83ad763b

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

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

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

From tr at openjdk.org  Tue Dec 19 05:08:39 2023
From: tr at openjdk.org (Tejesh R)
Date: Tue, 19 Dec 2023 05:08:39 GMT
Subject: RFR: 8187759: Background not refreshed when painting over a
 transparent JFrame
In-Reply-To: <aNVOH_vfzkXHlXEJ88tJf_d0YfheYj-5fazAldHhrfc=.0ae770d2-9c64-43d6-b565-05d710e01051@github.com>
References: <A-0sdTMigR7r9t_uzMLPHolzp3w2I5u-P1DXbCLV1X4=.8b66398a-e88d-4fc2-848f-a02dac236ccc@github.com>
 <p6K402lvUV56faEaufmosTRLo8-6DTIDOu6yblDaJ64=.b1bd614c-2600-46c3-b785-dac5f2270fe8@github.com>
 <yHOWBR1bDoS0NtrozRxKdy3KDxD3OtMjplWW_mlsz48=.7317de1f-8b8b-4cef-aa3d-7e2f69f4dbc8@github.com>
 <aNVOH_vfzkXHlXEJ88tJf_d0YfheYj-5fazAldHhrfc=.0ae770d2-9c64-43d6-b565-05d710e01051@github.com>
Message-ID: <swvZsjJVMWgIYz-UB2l8vMb5ioSb_pbVBHS909HzZE0=.24679a7c-ec1f-4dfb-b4f9-bd03b44d82d0@github.com>

On Mon, 18 Dec 2023 16:15:09 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > > This is happening in linux
> > > > Is it the Linux only? If yes why it cannot be reproduced on macOS and Windows?
> > 
> > 
> > Yes, This is happening only in linux. The paintToOffScreen is done by BufferStrategyPaintManager rather than RepaintManager (which is the case in macOS and Windows).
> 
> Renjith @Renjithkannath worked on a similar bug, [JDK-8256639](https://bugs.openjdk.org/browse/JDK-8256639): _Test `javax/swing/JPopupMenu/7160604/bug7160604.java` fails on Ubuntu_, and he reproduced the problem on macOS too, yet you have to make popups lightweight, they're heavyweight on macOS by default.
> 
> He tracked it down to the same root cause. His suggested fix was very similar to the one that @TejeshR13 proposes here. I wasn't convinced at that time that it was the best fix but I hadn't had time to look into it further.
> 
> Neither have I looked at this code review thoroughly yet.
> 
> Unfortunately, JDK-8256639 cannot be opened because it contains confidential information in its description.

Yeah, looks like both the issue has the same root cause... As per my analysis in bufferStrategyManager the Graphics used is `bsg` rather than what is passed down from Component. I confirmed the root cause by passing down the component Graphics to Offscreen painting where the issue didn't reproduce. Hence clearing the `bsg` Graphics solves the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/17081#issuecomment-1862124907

From asemenov at openjdk.org  Wed Dec 20 09:34:04 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 20 Dec 2023 09:34:04 GMT
Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard freezes
 the application in macOS 14 Sonoma
Message-ID: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com>

NSAccessibility Outline is an accessibility representation of trees.
This representation requires that the visible children be represented as a flat array.
The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children.
For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility.

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

Commit messages:
 -     8317771 [macos14] Expand/collapse a JTree using keyboard freezes the application in macOS 14 Sonoma

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

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

From aivanov at openjdk.org  Wed Dec 20 16:08:54 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 20 Dec 2023 16:08:54 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java
In-Reply-To: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
References: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
Message-ID: <7chZD7vCXTubISOJnw8mbVwbewmqJ-Gomqt6vRV-pHc=.6ce1d61d-da18-4870-ac5d-038e12f38767@github.com>

On Fri, 8 Dec 2023 03:23:22 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

> Hi Reviewers,
> 
> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. Please review and let me know your suggestions.
> 
> Regards,
> Renjith.

Changes requested by aivanov (Reviewer).

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 44:

> 42: import java.awt.Font;
> 43: import java.awt.Graphics;
> 44: import java.awt.image.BufferedImage;

Please put `java.awt`  imports above `javax.*` with an optional blank line between them.

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 44:

> 42: public class bug5049549 {
> 43: 
> 44:     private static ImageIcon DE = new ImageIcon(bug5049549.class.getResource("DE1.gif"));

private static ImageIcon DE = generateImage("DE");

Preserve the original code style? I have no strong preference between the two in this case.

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 54:

> 52: 
> 53:         BufferedImage img = new BufferedImage(40, 30,
> 54:                 BufferedImage.TYPE_INT_RGB);

Suggestion:

    private static Icon generateImage(String str) {
        BufferedImage img = new BufferedImage(40, 30,
                BufferedImage.TYPE_INT_RGB);

A blank line between a method declaration and its first statement doesn't make much sense, I'm for removing this blank line.

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 59:

> 57:         g.fillRect(0, 0, img.getWidth(), img.getHeight());
> 58:         g.setColor(Color.RED);
> 59:         Font font = new Font("SANS_SERIF", Font.BOLD, 22);

Suggestion:

        Font font = new Font(Font.SANS_SERIF, Font.BOLD, 22);

`"SANS_SERIF"` is wrong, you should use the constant `SANS_SERIF` in the `Font` class, and its value is `"SansSerif"`,

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 61:

> 59:         Font font = new Font("SANS_SERIF", Font.BOLD, 22);
> 60:         g.setFont(font);
> 61:         g.drawString(str,5,25);

Suggestion:

        g.drawString(str, 5, 25);

Spaces after commas.

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 116:

> 114:         KButton button;
> 115: 
> 116:         Icon DE = generateImage("DE");

If you prefer local variables, I'd move the declaration of `KButton` below the icons.

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 122:

> 120:         Icon RS = generateImage("DI");
> 121:         Icon SE = generateImage("DS");
> 122:         Icon PR = generateImage("RO");

Suggestion:

        Icon RS = generateImage("RS");
        Icon SE = generateImage("SE");
        Icon PR = generateImage("PR");

Fix copy-and-paste mistakes. Otherwise, the test fails because a _wrong_ icon is displayed.

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

PR Review: https://git.openjdk.org/jdk/pull/17029#pullrequestreview-1791194297
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1432904403
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1432906687
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1432903396
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1432897807
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1432898170
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1432901376
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1432886628

From aivanov at openjdk.org  Wed Dec 20 17:02:01 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 20 Dec 2023 17:02:01 GMT
Subject: RFR: 6510914: JScrollBar.getMinimumSize() breaks the contract of
 JComponent.setMinimumSize() [v6]
In-Reply-To: <GnN1P9Pe5E2e68nwW4zoHsG-wNWqpNcGDnRAOA7ehWs=.b40c23a3-ed93-4cd6-b158-391247d3c759@github.com>
References: <2oFB3wU5gns6b5ZLaFhsURai_16OLzSm6wYuoGeHK3Y=.c942050f-9d03-4989-b9a2-6836abf7a055@github.com>
 <qhzKuqEOTOyq0349997fRa_nLWS_kspAO7_iA2RyTvk=.b7be70d7-a7a6-4fbe-9208-900a3bce85b4@github.com>
 <GnN1P9Pe5E2e68nwW4zoHsG-wNWqpNcGDnRAOA7ehWs=.b40c23a3-ed93-4cd6-b158-391247d3c759@github.com>
Message-ID: <PcvQL80fceyCb4mWWqLIYStSE_xIwH6pGlhNI6J_CrU=.1319f9b1-c4e2-44b5-b619-a495ed11fb78@github.com>

On Mon, 20 Nov 2023 12:54:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > > But I do have another suggestion that actually might have been the best thing to do all those years ago. Keep the over-ride as the default behaviour, and document it better. But if the app calls setMaximumSize or setMinimumSize() then honour it like you are supposed to. I suspect very few apps actually call these since they are complete no-ops today. If we do that, then yes, you'll still see differences if you do call those APIs and forgot about it because it didn't make a difference.
> > 
> > 
> > Do you mean this way https://openjdk.github.io/cr/?repo=jdk&pr=15325&range=01#sdiff-0-src/java.desktop/share/classes/javax/swing/JScrollBar.java what I had done in the initial iteration? I guess that change will still show the above problem during frame resize, where scrollbars are not rigid
> 
> This is how I understand Phil's comment.

As I understand Phil's comment, he suggests using the implementation that you used in the first iteration of this fix:

https://github.com/openjdk/jdk/blob/31bbdee8ea71f43eb4863af50b398170a7b81ed2/src/java.desktop/share/classes/javax/swing/JScrollBar.java#L762-L772

That is we preserve the current behaviour of `getMinimumSize()` and `getMaximumSize()` methods in `JScrollBar`, yet if `setMinimumSize()` or `setMaximumSize()` is called, the corresponding `get-` methods return the set value and thus they follow the contract specified in `JComponent`.

@prrace, could you confirm, please?

> > I guess that change will still show the above problem during frame resize, where scrollbars are not rigid
> 
> Yes, it will, this is why update to the javadoc of `getMinimumSize` and `getMaximumSize` is required?to document their default behaviour and the fallback to returning the set sizes as per `JComponent` specification of `setMinimumSize` and `setMaximumSize`.

Maybe, overriding `setMinimumSize` and `setMaximumSize` isn't needed if we respect the `JComponent` contract. However, the specification of `getMinimumSize` and `getMaximumSize` needs updating to clarify what is returned.

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

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

From alexey.ivanov at oracle.com  Wed Dec 20 17:44:07 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Wed, 20 Dec 2023 17:44:07 +0000
Subject: WindowsLookAndFeel change in JDK 22
In-Reply-To: <c4cd0602-c68a-c6cd-a5f7-e548562d2d00@cjnash.com>
References: <10f5ecc2-7391-2555-0086-59de916f564a@cjnash.com>
 <09ecc349-10d1-42c3-b368-3af7d6963ad9@oracle.com>
 <1dae44cd-9a60-a5e9-d7aa-b21c674e8958@cjnash.com>
 <55cbe99a-6005-43e5-a93a-a1ace9929e66@oracle.com>
 <bd3da4f6-a7c2-b00f-2c7d-f52fdd3b1e4f@cjnash.com>
 <f8a23e32-e1df-4f48-928b-3d05fa2850b3@oracle.com>
 <d64d2551-07d0-de02-5512-1f4aea8c1c72@cjnash.com>
 <b1e3f689-bab5-482c-a9de-84d272e943ab@oracle.com>
 <c4cd0602-c68a-c6cd-a5f7-e548562d2d00@cjnash.com>
Message-ID: <0e5b9994-5e2b-40e3-813f-d9ff6d5957f8@oracle.com>

Hi Simon,

On 2023-12-15 22:04, Simon Nash wrote:
> Thanks for looking into this. I'm commenting here because I don't 
> think I am able to to add comments in JDK-8321151.

To add comments to JBS, you have to have a role the OpenJDK Census [7].

> if exact scaling is difficult, any reasonable approximation would be 
> better than falling back to the Windows NT LookAndFeel, as Phil Race 
> has commented in JDK-8321151.

Rajat is working on a fix, the fallback behaviour will be the same as it 
was before JDK-8294427. Once a PR is open, you'll be able to take the 
code changes for testing, however, you'll need to build JDK yourself. 
The PR will be announced with a message to the 
client-libs-dev at openjdk.org mailing list, as usual. If you're subscribed 
to the mailing list, you'll get the message in your inbox, 
alternatively, you can view the archives [8].

> On 11/12/2023 15:01, Aleksei Ivanov wrote:
>> This has been tracked down to be a regression of JDK-8294427 [1] 
>> which introduced the dependency on the OpenThemeDataForDpi [2] 
>> function from Windows API. The function is available since Windows 10 
>> version 1703.
>>
>> The code review [3] for JDK-8294427 has a discussion [4] on whether 
>> support for older versions of Windows should be considered.
>>
>> At that time, it was deemed infeasible [5] to provide this support.
>>
>> The compatibility problem is now tracked as JDK-8321151 [6].
>>
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8294427
>> [2] 
>> https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi
>> [3] https://github.com/openjdk/jdk/pull/13701
>> [4] https://github.com/openjdk/jdk/pull/13701#discussion_r1180829485
>> [5] https://github.com/openjdk/jdk/pull/13701#discussion_r1227202738
>> [6] https://bugs.openjdk.org/browse/JDK-8321151
[7] https://openjdk.org/census
[8] https://mail.openjdk.org/pipermail/client-libs-dev/

-- 
Regards,
Alexey

From rmahajan at openjdk.org  Thu Dec 21 01:26:13 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Thu, 21 Dec 2023 01:26:13 GMT
Subject: RFR: 8321151: JDK-8294427 breaks Windows L&F on all older Windows
 versions
Message-ID: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>

**Issue:**
https://bugs.openjdk.org/browse/JDK-8294427 starts to use this API
https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi

which was introduced only in Windows 10 1703.
So the theming engine won't load on anything earlier like the original windows 10 or windows 8.1 etc.

So as an undocumented side-effect it completely breaks the theming of Windows L&F on anything earlier
and it falls back to hard-coded rendering like Windows NT/Windows 2000

Whilst those older versions are technically out of at least "mainstream" support, this is not the way
to make that breaking change and I see this fix has been backported to older releases which expect stability

it seems to me that this code should NOT fail if the new API is missing and instead fall back to the old code.
No one will care about a pixel being off on hi-dpi if the entire UI is wrong.

**Fix:**
Added fallback path to support older versions of Windows that do not support OpenThemeDataForDpi().

**Testing:**
Tested on my Windows 10 machine with and without the fallback path and it works as expected.
Alexey tested on Windows 7 and on Windows 10 v1607 ? it works correctly (jdk 21.0.2 can't render themes as reported).
He also tested on Windows 11 .

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

Commit messages:
 - code cleanup
 - Ensure either OpenThemeDataForDpiFunc or OpenThemeDataFunc is present
 - Declare InitThemes and rescale as static
 - Re-wrap the conditional operator with -ForDpiFunc
 - Move defaultDPI to global context
 - Updated changes
 - execute fall-back

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

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

From rkannathpari at openjdk.org  Thu Dec 21 03:56:58 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 21 Dec 2023 03:56:58 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java [v2]
In-Reply-To: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
References: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
Message-ID: <VlPf_2qC5UD72kJNxZWq3Z0Aq6czxcXfXnuBSW6aNTs=.652f49f3-96f4-4b33-9e23-73f4ab4e9a1c@github.com>

> Hi Reviewers,
> 
> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. 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:

  Fixed typo and integrated suggsions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17029/files
  - new: https://git.openjdk.org/jdk/pull/17029/files/8a747cb2..3be79267

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

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

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

From rkannathpari at openjdk.org  Thu Dec 21 04:08:57 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 21 Dec 2023 04:08:57 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java [v3]
In-Reply-To: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
References: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
Message-ID: <qWBEiERxVAMKYtFBQQzI3PAjApqA28omtbuk1FDKrTo=.ae540a6f-c4fc-4c88-9699-406daa79dc18@github.com>

> Hi Reviewers,
> 
> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. Please review and let me know your suggestions.
> 
> Regards,
> Renjith.

Renjith Kannath Pariyangad has updated the pull request incrementally with two additional commits since the last revision:

 - Added space befor number
 - Added space befor number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17029/files
  - new: https://git.openjdk.org/jdk/pull/17029/files/3be79267..fa44c8d1

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

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

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

From rkannathpari at openjdk.org  Thu Dec 21 04:24:10 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 21 Dec 2023 04:24:10 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java [v4]
In-Reply-To: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
References: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
Message-ID: <Lpas_f4pYZLJyRSWq5VadXSLBlTvOpgoXUNL07gwaic=.ccba5332-dcd2-4bc9-a5da-928b69f59dcc@github.com>

> Hi Reviewers,
> 
> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. 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:

  Reverted space befor line for minimal change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17029/files
  - new: https://git.openjdk.org/jdk/pull/17029/files/fa44c8d1..87bf8094

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

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

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

From aivanov at openjdk.org  Thu Dec 21 11:00:53 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 21 Dec 2023 11:00:53 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java [v4]
In-Reply-To: <Lpas_f4pYZLJyRSWq5VadXSLBlTvOpgoXUNL07gwaic=.ccba5332-dcd2-4bc9-a5da-928b69f59dcc@github.com>
References: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
 <Lpas_f4pYZLJyRSWq5VadXSLBlTvOpgoXUNL07gwaic=.ccba5332-dcd2-4bc9-a5da-928b69f59dcc@github.com>
Message-ID: <dujTjRCq0Q_OoCIiEhFEPOM8rW43xVwxwUp9VWitPqI=.041dace3-e883-470f-85e9-51aefaece9b9@github.com>

On Thu, 21 Dec 2023 04:24:10 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers,
>> 
>> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. 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:
> 
>   Reverted space befor line for minimal change

Marked as reviewed by aivanov (Reviewer).

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 46:

> 44: */
> 45: 
> 46: public class bug5049549 {

Since you're moving it, I suggest formatting it according to conventions used in most tests:
Suggestion:

/*
 * @test
 * @bug 5049549 7132413
 * @summary Tests that the proper icon is used for different states.
 * @library ../../regtesthelpers
 * @build Blocker
 * @run main/manual bug5049549
 */
public class bug5049549 {

That is with starting asterisk on each line, and align the last asterisk.

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 54:

> 52:     private static Icon RS = generateImage("RS");
> 53:     private static Icon SE = generateImage("SE");
> 54:     private static Icon PR = generateImage("PR");

I suggest marking all of them `final`:
Suggestion:

    private static final Icon DE = generateImage("DE");
    private static final Icon DI = generateImage("DI");
    private static final Icon DS = generateImage("DS");
    private static final Icon RO = generateImage("RO");
    private static final Icon RS = generateImage("RS");
    private static final Icon SE = generateImage("SE");
    private static final Icon PR = generateImage("PR");

test/jdk/javax/swing/AbstractButton/5049549/bug5049549.java line 56:

> 54:     private static Icon PR = generateImage("PR");
> 55: 
> 56:     private static Blocker blocker = new Blocker();

I'd add `final` modifier to `blocker` too.

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

PR Review: https://git.openjdk.org/jdk/pull/17029#pullrequestreview-1792731407
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1433914096
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1433910450
PR Review Comment: https://git.openjdk.org/jdk/pull/17029#discussion_r1433911187

From aivanov at openjdk.org  Thu Dec 21 18:41:48 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 21 Dec 2023 18:41:48 GMT
Subject: RFR: 8321151: JDK-8294427 breaks Windows L&F on all older Windows
 versions
In-Reply-To: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>
References: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>
Message-ID: <E00AJ4N8dbiHDxZisbwp9ZX85NBqmvb41ZatBSTheiw=.4096134c-0de0-4a55-8bb9-b973c708e27b@github.com>

On Thu, 21 Dec 2023 01:19:40 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Issue:**
> https://bugs.openjdk.org/browse/JDK-8294427 starts to use this API
> https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi
> 
> which was introduced only in Windows 10 1703.
> So the theming engine won't load on anything earlier like the original windows 10 or windows 8.1 etc.
> 
> So as an undocumented side-effect it completely breaks the theming of Windows L&F on anything earlier
> and it falls back to hard-coded rendering like Windows NT/Windows 2000
> 
> Whilst those older versions are technically out of at least "mainstream" support, this is not the way
> to make that breaking change and I see this fix has been backported to older releases which expect stability
> 
> it seems to me that this code should NOT fail if the new API is missing and instead fall back to the old code.
> No one will care about a pixel being off on hi-dpi if the entire UI is wrong.
> 
> **Fix:**
> Added fallback path to support older versions of Windows that do not support OpenThemeDataForDpi().
> 
> **Testing:**
> Tested on my Windows 10 machine with and without the fallback path and it works as expected.
> Alexey tested on Windows 7 and on Windows 10 v1607 ? it works correctly (jdk 21.0.2 can't render themes as reported).
> He also tested on Windows 11 .

Looks good to me.

I tested it on Windows 7, Windows 10 v1607 as well as current versions of Windows 10 and 11. I ran SwingSet2 side-by-side and I didn't spot any differences.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17173#pullrequestreview-1793493900

From achung at openjdk.org  Thu Dec 21 19:31:48 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 21 Dec 2023 19:31:48 GMT
Subject: RFR: 8321151: JDK-8294427 breaks Windows L&F on all older Windows
 versions
In-Reply-To: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>
References: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>
Message-ID: <xOsiu-gK51OiJ9gUjD6C63VbZ8Xibc-1MEqi6_qllBY=.dec5c68c-9587-4188-9cc4-958126616e9f@github.com>

On Thu, 21 Dec 2023 01:19:40 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Issue:**
> https://bugs.openjdk.org/browse/JDK-8294427 starts to use this API
> https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi
> 
> which was introduced only in Windows 10 1703.
> So the theming engine won't load on anything earlier like the original windows 10 or windows 8.1 etc.
> 
> So as an undocumented side-effect it completely breaks the theming of Windows L&F on anything earlier
> and it falls back to hard-coded rendering like Windows NT/Windows 2000
> 
> Whilst those older versions are technically out of at least "mainstream" support, this is not the way
> to make that breaking change and I see this fix has been backported to older releases which expect stability
> 
> it seems to me that this code should NOT fail if the new API is missing and instead fall back to the old code.
> No one will care about a pixel being off on hi-dpi if the entire UI is wrong.
> 
> **Fix:**
> Added fallback path to support older versions of Windows that do not support OpenThemeDataForDpi().
> 
> **Testing:**
> Tested on my Windows 10 machine with and without the fallback path and it works as expected.
> Alexey tested on Windows 7 and on Windows 10 v1607 ? it works correctly (jdk 21.0.2 can't render themes as reported).
> He also tested on Windows 11 .

Looks fine

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

Marked as reviewed by achung (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17173#pullrequestreview-1793550645

From honkar at openjdk.org  Thu Dec 21 20:38:54 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 21 Dec 2023 20:38:54 GMT
Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails
 intermittently on macOS 14
Message-ID: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>

ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2.

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

Commit messages:
 - copyright year updated
 - Test stabilization fix for macOS 14

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

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

From kizune at openjdk.org  Thu Dec 21 21:15:47 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Thu, 21 Dec 2023 21:15:47 GMT
Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard
 freezes the application in macOS 14 Sonoma
In-Reply-To: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com>
References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com>
Message-ID: <sHSfScxHvWt0Sx5BSWF2On3DoeqhHRI34yn_5l59L9I=.33727004-60e5-4785-9f96-df0a2023d99c@github.com>

On Wed, 20 Dec 2023 09:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> NSAccessibility Outline is an accessibility representation of trees.
> This representation requires that the visible children be represented as a flat array.
> The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children.
> For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility.

src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 799:

> 797:                         for (int i = 0; i < count; i++) {
> 798:                             TreePath path = tree.getPathForRow(i);
> 799:                             Accessible an = createAccessibleTreeNode(tree, path);

I see that you are creating the accessible tree node with reflection calling its constructor. Can you just elaborate if it is the only way to get hold of it and why getting a tree.getAccessible().getAccessibleChild(i) does not work or what kind of problem getting the tree node this way creates?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17165#discussion_r1434518050

From aturbanov at openjdk.org  Thu Dec 21 21:27:39 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 21 Dec 2023 21:27:39 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix [v2]
In-Reply-To: <EHfslq0NmzcHtTF8JPSJIlhytsAlzk_Esn8mbGXfRLQ=.1b7e9d62-df2d-4128-9ecd-0144fe81c606@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
 <EHfslq0NmzcHtTF8JPSJIlhytsAlzk_Esn8mbGXfRLQ=.1b7e9d62-df2d-4128-9ecd-0144fe81c606@github.com>
Message-ID: <6cCC_D9BGp2Qr4KvM44Rv4xsWjDnVAeZKx1Vx9MuIek=.5b8efdc8-a60c-4586-ad25-68b964dce599@github.com>

On Thu, 7 Dec 2023 09:17:05 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers, 
>> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
>> 
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test case

test/jdk/java/awt/color/NonICCFilterTest.java line 79:

> 77:                 raster.getWidth(), raster.getHeight(), Color.BLUE);
> 78:         g.setPaint(gp);
> 79:         g.fillRect(0,0,raster.getWidth(), raster.getHeight());

Suggestion:

        g.fillRect(0, 0, raster.getWidth(), raster.getHeight());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16895#discussion_r1434524762

From dnguyen at openjdk.org  Thu Dec 21 21:37:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Thu, 21 Dec 2023 21:37:46 GMT
Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails
 intermittently on macOS 14
In-Reply-To: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
References: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
Message-ID: <ZTBIKU3VUJllgH_Vki9Ewpt8u6Bav155Xw8sLkvpABQ=.f46f4de9-3dcd-4867-a373-b342cd7b0efa@github.com>

On Thu, 21 Dec 2023 20:33:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2.

I tested this locally on my macOS 14.1.2 device and the test DID intermittently fail without the fix at different attempt #'s. But, with the updated test, the test is passing every time. Ran the test 10x and still passes. Stability fix looks good to me

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17180#pullrequestreview-1793700915

From rkannathpari at openjdk.org  Fri Dec 22 03:39:59 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 22 Dec 2023 03:39:59 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java [v5]
In-Reply-To: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
References: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
Message-ID: <jqwKbJ_eoHgTAd3Mill3PH4aZsquVt2tHkE14Jsu7Ws=.0f5acba9-c796-4f0e-8b2b-68cff81d1abc@github.com>

> Hi Reviewers,
> 
> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. 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 test param format

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17029/files
  - new: https://git.openjdk.org/jdk/pull/17029/files/87bf8094..14616c9d

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

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

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

From rkannathpari at openjdk.org  Fri Dec 22 03:54:53 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 22 Dec 2023 03:54:53 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix [v3]
In-Reply-To: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
Message-ID: <USNyLOnqHXiz7iyZk1gsEwv8EY3_2780q-g8qKmai6w=.6bd316b0-5a8e-498a-a529-a08270d6caae@github.com>

> Hi Reviewers, 
> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
> 
> Renjith.

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

  Integrated suggesions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16895/files
  - new: https://git.openjdk.org/jdk/pull/16895/files/b7faa3a7..71748d39

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

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

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

From rkannathpari at openjdk.org  Fri Dec 22 04:03:14 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 22 Dec 2023 04:03:14 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix [v4]
In-Reply-To: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
Message-ID: <TkrqwW9LZdVkUzXSustHxnBSVgCYTVi9PHYKuu3L5Us=.27cb4486-3b66-4327-a524-e9cde0bd1674@github.com>

> Hi Reviewers, 
> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
> 
> Renjith.

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

  Removed space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16895/files
  - new: https://git.openjdk.org/jdk/pull/16895/files/71748d39..1bf2cb3b

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

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

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

From rkannathpari at openjdk.org  Fri Dec 22 04:03:14 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Fri, 22 Dec 2023 04:03:14 GMT
Subject: RFR: 8316497 : ColorConvertOp - typo for non-ICC conversions needs
 one-line fix [v3]
In-Reply-To: <USNyLOnqHXiz7iyZk1gsEwv8EY3_2780q-g8qKmai6w=.6bd316b0-5a8e-498a-a529-a08270d6caae@github.com>
References: <hv-fy4lTEz-ESNXTnn6IInZzMo-hBRyySDYktqCWajM=.e8e196e3-607e-4469-88fc-015ca41e04ce@github.com>
 <USNyLOnqHXiz7iyZk1gsEwv8EY3_2780q-g8qKmai6w=.6bd316b0-5a8e-498a-a529-a08270d6caae@github.com>
Message-ID: <1_b-yA5pWp_D_OLMxh4TDMFfpSgiDESjjYqcchy-WWI=.a18dc653-b159-46ff-aa13-a5226fba5a1d@github.com>

On Fri, 22 Dec 2023 03:54:53 GMT, Renjith Kannath Pariyangad <rkannathpari at openjdk.org> wrote:

>> Hi Reviewers, 
>> There was a typo for color conversion instead of dstColorSpace function srcColorSpace was used. Please review and let me know your suggestions if any. 
>> 
>> Renjith.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Integrated suggesions

Thank you @turbanoff for your time and review, I have integrated your suggestions

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

PR Comment: https://git.openjdk.org/jdk/pull/16895#issuecomment-1867205997

From azvegint at openjdk.org  Fri Dec 22 08:19:45 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 22 Dec 2023 08:19:45 GMT
Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails
 intermittently on macOS 14
In-Reply-To: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
References: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
Message-ID: <nYMBEL6xccD6RV5ad935qdc73YenBbuonKZE5a6ikhI=.9b632a6f-5b5d-4657-bd1a-6dce1f83e984@github.com>

On Thu, 21 Dec 2023 20:33:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17180#pullrequestreview-1794124100

From abhiscxk at openjdk.org  Fri Dec 22 08:24:51 2023
From: abhiscxk at openjdk.org (Abhishek Kumar)
Date: Fri, 22 Dec 2023 08:24:51 GMT
Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test
 Instructions.
In-Reply-To: <aPXGtFOu01x-HnIwlm9SU16yEd_JWGuStIkkm-r99hg=.e67e0f12-4a5f-4a81-8e2d-4484c3f6bc7d@github.com>
References: <aPXGtFOu01x-HnIwlm9SU16yEd_JWGuStIkkm-r99hg=.e67e0f12-4a5f-4a81-8e2d-4484c3f6bc7d@github.com>
Message-ID: <0Q5V2S5EK86uFt_WbVbHin7CuNrncr98f9tcZZpHlYI=.46d77059-1eb8-408d-aa84-577588cfa00a@github.com>

On Thu, 14 Dec 2023 10:52:29 GMT, Tejesh R <tr at openjdk.org> wrote:

> By default `JTable.setColumnSelectionAllowed()` is set to false in `DefaultTableColumnModel` class and `JTable.setRowSelectionAllowed()` is set to true in `JTable` class. In order to navigate table as per [JDK-4112270](https://bugs.openjdk.org/browse/JDK-4112270), column selection to be made true.

Any specific reason behind setting `setColumnSelectionAllowed()` to false in `DefaultTableColumnModel` whereas `setRowSelectionAllowed` is set to true ?

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

PR Comment: https://git.openjdk.org/jdk/pull/17105#issuecomment-1867380198

From tr at openjdk.org  Fri Dec 22 08:35:53 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 22 Dec 2023 08:35:53 GMT
Subject: RFR: 8264102: JTable Keyboards Navigation differs with Test
 Instructions.
In-Reply-To: <0Q5V2S5EK86uFt_WbVbHin7CuNrncr98f9tcZZpHlYI=.46d77059-1eb8-408d-aa84-577588cfa00a@github.com>
References: <aPXGtFOu01x-HnIwlm9SU16yEd_JWGuStIkkm-r99hg=.e67e0f12-4a5f-4a81-8e2d-4484c3f6bc7d@github.com>
 <0Q5V2S5EK86uFt_WbVbHin7CuNrncr98f9tcZZpHlYI=.46d77059-1eb8-408d-aa84-577588cfa00a@github.com>
Message-ID: <BbTK_alScFbwXFyPYAazC6Q95F_BuNrRTCoQ8miJMxA=.0f39f7b1-a61a-4556-ae72-7c3760e318b3@github.com>

On Fri, 22 Dec 2023 08:21:54 GMT, Abhishek Kumar <abhiscxk at openjdk.org> wrote:

> Any specific reason behind setting `setColumnSelectionAllowed()` to false in `DefaultTableColumnModel` whereas `setRowSelectionAllowed` is set to true ?

Don't know since it was initial load. Only Row selection is enabled in JTable. In this particular test if user wants to check keyboard operations then setting column and row selection has to be true.

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

PR Comment: https://git.openjdk.org/jdk/pull/17105#issuecomment-1867389936

From jbechberger at openjdk.org  Fri Dec 22 11:32:05 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 22 Dec 2023 11:32:05 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
Message-ID: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>

A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.

This fix is tested and fixes the issue.

I attached a small
[reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

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

Commit messages:
 - Fix bug

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

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

From tr at openjdk.org  Fri Dec 22 13:44:56 2023
From: tr at openjdk.org (Tejesh R)
Date: Fri, 22 Dec 2023 13:44:56 GMT
Subject: Withdrawn: 8264102: JTable Keyboards Navigation differs with Test
 Instructions.
In-Reply-To: <aPXGtFOu01x-HnIwlm9SU16yEd_JWGuStIkkm-r99hg=.e67e0f12-4a5f-4a81-8e2d-4484c3f6bc7d@github.com>
References: <aPXGtFOu01x-HnIwlm9SU16yEd_JWGuStIkkm-r99hg=.e67e0f12-4a5f-4a81-8e2d-4484c3f6bc7d@github.com>
Message-ID: <8jRONdlCcn4uBUZ1_58PGd3LJ7OM6UR09YhpNjLHRx8=.57756481-c994-4a2e-bcf3-99d24f8aa9d2@github.com>

On Thu, 14 Dec 2023 10:52:29 GMT, Tejesh R <tr at openjdk.org> wrote:

> By default `JTable.setColumnSelectionAllowed()` is set to false in `DefaultTableColumnModel` class and `JTable.setRowSelectionAllowed()` is set to true in `JTable` class. In order to navigate table as per [JDK-4112270](https://bugs.openjdk.org/browse/JDK-4112270), column selection to be made true.

This pull request has been closed without being integrated.

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

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

From kcr at openjdk.org  Fri Dec 22 15:10:45 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Dec 2023 15:10:45 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
Message-ID: <C1GSxcIpIcx6OeMqYuOBHHGYmfleWl9bjz0CiTPccPQ=.7ba44b45-a0bd-4b8a-8a7e-c044db90b08a@github.com>

On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.
> 
> This fix is tested and fixes the issue.
> 
> I attached a small
> [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

@parttimenerd I can test this with JavaFX on macOS, but you need to provide a better evaluation that explains what the root cause of the deadlock is and why this is the right way to fix it. Saying that the deadlock "can apparently be prevented by ..." is not an evaluation. The change you propose is in a fundamental method in AWT, so you will also need to show that this will not cause any regressions.

Reviewers: @kevinrushforth @prrace @prsadhuk

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

PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1867793976

From jbechberger at openjdk.org  Fri Dec 22 15:26:46 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 22 Dec 2023 15:26:46 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
Message-ID: <nADrZO9AJDHgWxGb6gFmD07QCPW-RH7kWI8vqtrTEQQ=.c2b39388-7c01-469a-b41a-9ba4e9bc14bb@github.com>

On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.
> 
> This fix is tested and fixes the issue.
> 
> I attached a small
> [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

Thank you for your comment, I'm in the middle of understanding the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1867810291

From kcr at openjdk.org  Fri Dec 22 16:20:45 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Dec 2023 16:20:45 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
Message-ID: <jqCbVx_qXZgzQxsbYxFSrQmROVbzJgIkzuA3ND3UwX8=.e9f07ebc-c2af-4bad-9ff7-35515355a3d9@github.com>

On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.
> 
> This fix is tested and fixes the issue.
> 
> I attached a small
> [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

I note that your proposed solution was originally pointed out as a workaround by Arunprasad Rajkumar in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8221261?focusedId=14255770&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14255770).

One possible problem with the above workaround is mentioned in [this comment](https://github.com/openjdk/jdk/blob/bef94378ddf33ab29a36e1ceee48890a5b5c7a9d/src/java.desktop/macosx/classes/sun/lwawt/macosx/LWCToolkit.java#L930) describing the `processEvents` parameter (the one you are changing from `false` to `true`) in the `doAWTRunLoop` method:

"Additional attention is needed when using this feature as we short-circuit normal event processing which could break Appkit"

Anton Tarasov proposed a modified solution, in [this JBS comment](https://bugs.openjdk.org/browse/JDK-8221261?focusedId=14263545&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14263545), that spins up a nested event loop that processes events only for the `firstRectForCharacterRange` and `characterIndexForPoint` methods in `CInputMethod`. Presuming that this is the right place to fix it, this seems a safer approach, although still needs to be evaluated.

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

PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1867861682

From kcr at openjdk.org  Fri Dec 22 16:26:38 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Dec 2023 16:26:38 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
Message-ID: <DAOPdHCWyuzDRVwaW1Wo9RgGgisO_kHJutfSDCm6jw0=.185d0ad3-6caf-4ef5-bb72-95548c81e9b1@github.com>

On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.
> 
> This fix is tested and fixes the issue.
> 
> I attached a small
> [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

Btw, using a simple Swing app with a WebView inside a JFXPanel (similar to the test program referred in the Description), I can consistently reproduce this deadlock on my Mac M1 running macOS 14.1.2. I'll try this on macOS 13.x as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1867867059

From kcr at openjdk.org  Fri Dec 22 16:36:38 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Dec 2023 16:36:38 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
Message-ID: <Ge_nQxW6TniC5vYON0rx2SBNimH8zbkGzoNLVWasRJs=.58d2ee23-19da-4cba-a64d-91a71121748f@github.com>

On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.
> 
> This fix is tested and fixes the issue.
> 
> I attached a small
> [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

By selecting Japanese input, I can also easily reproduce this on macOS 13.x.

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

PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1867875875

From kizune at openjdk.org  Fri Dec 22 19:30:46 2023
From: kizune at openjdk.org (Alexander Zuev)
Date: Fri, 22 Dec 2023 19:30:46 GMT
Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails
 intermittently on macOS 14
In-Reply-To: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
References: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
Message-ID: <E1lo_hhBhWLy4evYzvH5kssqjF_vae8_m0IPQm1cZYQ=.e4fe9ceb-a5e0-4326-aa94-1f9433c7cf65@github.com>

On Thu, 21 Dec 2023 20:33:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2.

Looks good

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

Marked as reviewed by kizune (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17180#pullrequestreview-1794925628

From rmahajan at openjdk.org  Fri Dec 22 20:19:53 2023
From: rmahajan at openjdk.org (Rajat Mahajan)
Date: Fri, 22 Dec 2023 20:19:53 GMT
Subject: Integrated: 8321151: JDK-8294427 breaks Windows L&F on all older
 Windows versions
In-Reply-To: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>
References: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>
Message-ID: <GEQTUv2GcUZd10SOaZuNIpi-EoXcYQwcn3XtyodK9eI=.05d4d44d-be0f-4eb6-b06d-812e2eaed917@github.com>

On Thu, 21 Dec 2023 01:19:40 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:

> **Issue:**
> https://bugs.openjdk.org/browse/JDK-8294427 starts to use this API
> https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/nf-uxtheme-openthemedatafordpi
> 
> which was introduced only in Windows 10 1703.
> So the theming engine won't load on anything earlier like the original windows 10 or windows 8.1 etc.
> 
> So as an undocumented side-effect it completely breaks the theming of Windows L&F on anything earlier
> and it falls back to hard-coded rendering like Windows NT/Windows 2000
> 
> Whilst those older versions are technically out of at least "mainstream" support, this is not the way
> to make that breaking change and I see this fix has been backported to older releases which expect stability
> 
> it seems to me that this code should NOT fail if the new API is missing and instead fall back to the old code.
> No one will care about a pixel being off on hi-dpi if the entire UI is wrong.
> 
> **Fix:**
> Added fallback path to support older versions of Windows that do not support OpenThemeDataForDpi().
> 
> **Testing:**
> Tested on my Windows 10 machine with and without the fallback path and it works as expected.
> Alexey tested on Windows 7 and on Windows 10 v1607 ? it works correctly (jdk 21.0.2 can't render themes as reported).
> He also tested on Windows 11 .

This pull request has now been integrated.

Changeset: f695ca58
Author:    Rajat Mahajan <rmahajan at openjdk.org>
Committer: Alexey Ivanov <aivanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f695ca588453265d6ad791c6a396197e8a53ba39
Stats:     54 lines in 1 file changed: 43 ins; 2 del; 9 mod

8321151: JDK-8294427 breaks Windows L&F on all older Windows versions

Reviewed-by: aivanov, achung

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

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

From honkar at openjdk.org  Fri Dec 22 20:45:47 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 22 Dec 2023 20:45:47 GMT
Subject: RFR: JDK-8320113: [macos14] : ShapeNotSetSometimes.java fails
 intermittently on macOS 14
In-Reply-To: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
References: <P_5tpNDh-Phh3Qh9d1yP3K86cL1U5Jat_V-c_6UGxH4=.9beddf05-f489-4b26-b430-ffe4be9d6647@github.com>
Message-ID: <thfwgqxg5yveVKKsfujWB_Qp30r9skcvDQHlXugB__A=.ed5e16d1-db68-4749-ac53-cf3f92efcbdb@github.com>

On Thu, 21 Dec 2023 20:33:53 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

> ShapeNotSetSometimes.java fails intermittently on macOS 14. Following is a test stabilization fix for macOS 14. With the added delays ShapeNotSetSometimes.java passes on older versions of macOS as well as on macOS 14.1, 14.2.

This test is failing intermittently on linux with the current fix. Running the test on all platforms with slightly different delay values.

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

PR Comment: https://git.openjdk.org/jdk/pull/17180#issuecomment-1868056364

From kcr at openjdk.org  Fri Dec 22 20:56:37 2023
From: kcr at openjdk.org (Kevin Rushforth)
Date: Fri, 22 Dec 2023 20:56:37 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
Message-ID: <jQOzcV5P7BjiJsw0CNW120HeKheVQY0tSnEZswOWbOI=.dfd2d88a-a376-4b06-9691-94ebfc0d47ab@github.com>

On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.
> 
> This fix is tested and fixes the issue.
> 
> I attached a small
> [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

I can confirm that the proposed fix in this PR does eliminate the deadlocks, although as per the comment from Anton I referred to above, it is likely to have some side effects.

I did a quick prototype of Anton's idea, and ended up changing all five of the `invokeAndWait` calls in `CInputMethod` to pass in the `processEvents` flag, since just changing the two he pointed out did not fix all the possible sources of deadlock. Doing that, while leaving all other calls to `invokeAndWait` alone, is sufficient to avoid the deadlock. This might end up being the best fix, since it is less intrusive (thus less risky) that changing all invokeAntWait calls, and as Arunprasad noted in the JBS bug, we don't know of a way to avoid the deadlock by just changing FX code.

While doing some testing of the fix I ran into a few crashes where native WebKit code is being called on the AWT Event  thread, which suggest that other JavaFX WebView InputMethodClientImpl methods will likely need the same treatment that `firstRectForCharacterRange` and `characterIndexForPoint` got in the fix for [JDK-8196011](https://bugs.openjdk.org/browse/JDK-8196011). This crash isn't caused by fixing the deadlock, since I see it intermittently with a JDK without the deadlock fix (e.g., JDK 21.0.1). I'll file a separate JavaFX bug to track the crash.

We can  pick this up in the new year, since no one on our end will be around to look at it before then.

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

PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1868062432

From mark.yagnatinsky at barclays.com  Sat Dec 23 05:01:59 2023
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Sat, 23 Dec 2023 05:01:59 +0000
Subject: the easiest ways to play an audio clip are the discouraged ones
In-Reply-To: <MN2PR12MB3616B22F1211ECABC7D721EAF99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
References: <MN2PR12MB3616B22F1211ECABC7D721EAF99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
Message-ID: <MN2PR12MB3616013C893644BADEDAAC30F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>

Sorry for double-post; I think my fist attempt got blocked because I wasn't subscribed.
Also sorry if this is the wrong list; please redirect me if so.
ALSO ALSO sorry if this is a bit of a disorganized rant, but I'm a bit frustrated.

Suppose I have a sound file on my hard disk and want Java to play it.
By copying random code snippets off the internet, we can discover
sun.audio.AudioPlayer.player.start(java.io.InputStream file)

Easy!  But wait, the sun.* packages are not officially exported and javac 8 complains, and with modules it likely complains even louder.
Then we discover JavaFX has a nifty MediaPlayer which is almost as easy.  But JavaFX is "de-bundled" so that's a bit annoying.

No matter, we can use Applet.newAudioClip()!  We don't want an applet, this API works fine without them.  Nice!
But the entire applet namespace is deprecated, and even worse, it is deprecated for removal.
(For the record, I think deprecating it makes sense, but deprecating it for removal was a bad idea and should be undone.  But I'm an outsider, so whatever.)
Depending on things that are threatened to go away on possibly short notice seems risky, so let's not.

I see something called JMF (Java Media Framework) but that's also not bundled, and hard to even find docs for.  Sigh.

Let's looks at something nice and official: the sound tutorial:
https://docs.oracle.com/javase/tutorial/sound/playing.html
Oh dear, that looks complicated.  I guess we need to somehow get Clip?  How to do that?
The tutorial has a big warning on top that it hasn't been updated since Java 8 but I suspect it hasn't been touched since Java 5 or longer.
Well, in must have been touched a bit, since it uses Clip.class syntax which was added in Java 5.  But what it doesn't have is any mention of these methods:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4896221
My best explanation is that they got added after the tutorial was written, and then the tutorial was never updated, which I think reduces the amount of good those methods do.
But that's okay because we found those methods, one of which is called getClip().  Yay, we have Clip!
Now all we need to do is clip.open(AudioInputStream)... hmm.  Where do I get one of those?  The tutorial doesn't seem to say.
The official Javadocs have a neat feature where each interface lists all public classes that implement it.
What it does NOT have is a list of all methods whose return type "matches" the interface.
But that's okay, we have nice IDEs, so I can just "find usages" of AudioInputStream and filter down to those where it appears as a return type!
And there we go: I need AudioSystem.getAudioInputStream().
And then we're ready: we can call start() and it will play our clip!
Hmm... I wonder if the call returns when playback starts or only when it ends... maybe we need a scratch thread so it doesn't block us?
Oh and let's not forget to close() the clip when we're done!

This API seems to try pretty hard to give experts everything they need.
But it doesn't cater very well to the use case of "I don't know what a mixer is, and I wish I didn't have to care!"
The highly-nonofficial sun.audio.AudioPlayer does a pretty good job for this use-case; there should ideally be something at LEAST that easy in an official, non-deprecated API.

Just my two cents.
Mark

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231223/2a1ec162/attachment-0001.htm>

From duke at openjdk.org  Sat Dec 23 09:07:03 2023
From: duke at openjdk.org (duke)
Date: Sat, 23 Dec 2023 09:07:03 GMT
Subject: Withdrawn: 8221452: Window.setMinimumSize does not respect DPI scaling
In-Reply-To: <7fZ5gO65xyT8dqEjqv_B9rUXZWJDwLHMC-IjCOJ856M=.712cde39-b694-4542-9a06-3fdf5566e609@github.com>
References: <7fZ5gO65xyT8dqEjqv_B9rUXZWJDwLHMC-IjCOJ856M=.712cde39-b694-4542-9a06-3fdf5566e609@github.com>
Message-ID: <1za27ekClDzXP3IHqCw044PI_ti5PT9xtVEqfSZPguU=.63477af8-f6a4-4573-95af-86b063215a85@github.com>

On Mon, 8 May 2023 00:49:58 GMT, babblebubble <duke at openjdk.org> wrote:

> Hi, I'm not sure if I did the formatting of this pull request right, new to this, but the bug was bothering me so I fixed it (took three attempts).
> All I had to do was add ScaleUpX and ScaleUpY and it fixed it.
> Sorry for being new to GitHub, I only made an account to fix this.

This pull request has been closed without being integrated.

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

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

From mark.yagnatinsky at barclays.com  Sat Dec 23 21:07:04 2023
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Sat, 23 Dec 2023 21:07:04 +0000
Subject: the easiest ways to play an audio clip are the discouraged ones
In-Reply-To: <MN2PR12MB3616013C893644BADEDAAC30F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
References: <MN2PR12MB3616B22F1211ECABC7D721EAF99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
 <MN2PR12MB3616013C893644BADEDAAC30F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
Message-ID: <MN2PR12MB361619370CCA9790E58D6A21F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>

Also: the discouraged methods (applet-based and sun.audio.Player) are friendly enough to call Toolkit. getPCMConvertedAudioInputStream() for you.
Of course, you could do that yourself, except... this is ALSO not exposed.
So we need to re-implement that method.  Sigh.
The "official" way to do things should NOT be this hard!

From: Yagnatinsky, Mark : Markets Pre Trade
Sent: Saturday, December 23, 2023 12:02 AM
To: 'client-libs-dev at openjdk.org' <client-libs-dev at openjdk.org>
Subject: the easiest ways to play an audio clip are the discouraged ones

Sorry for double-post; I think my fist attempt got blocked because I wasn't subscribed.
Also sorry if this is the wrong list; please redirect me if so.
ALSO ALSO sorry if this is a bit of a disorganized rant, but I'm a bit frustrated.

Suppose I have a sound file on my hard disk and want Java to play it.
By copying random code snippets off the internet, we can discover
sun.audio.AudioPlayer.player.start(java.io.InputStream file)

Easy!  But wait, the sun.* packages are not officially exported and javac 8 complains, and with modules it likely complains even louder.
Then we discover JavaFX has a nifty MediaPlayer which is almost as easy.  But JavaFX is "de-bundled" so that's a bit annoying.

No matter, we can use Applet.newAudioClip()!  We don't want an applet, this API works fine without them.  Nice!
But the entire applet namespace is deprecated, and even worse, it is deprecated for removal.
(For the record, I think deprecating it makes sense, but deprecating it for removal was a bad idea and should be undone.  But I'm an outsider, so whatever.)
Depending on things that are threatened to go away on possibly short notice seems risky, so let's not.

I see something called JMF (Java Media Framework) but that's also not bundled, and hard to even find docs for.  Sigh.

Let's looks at something nice and official: the sound tutorial:
https://docs.oracle.com/javase/tutorial/sound/playing.html
Oh dear, that looks complicated.  I guess we need to somehow get Clip?  How to do that?
The tutorial has a big warning on top that it hasn't been updated since Java 8 but I suspect it hasn't been touched since Java 5 or longer.
Well, in must have been touched a bit, since it uses Clip.class syntax which was added in Java 5.  But what it doesn't have is any mention of these methods:
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4896221
My best explanation is that they got added after the tutorial was written, and then the tutorial was never updated, which I think reduces the amount of good those methods do.
But that's okay because we found those methods, one of which is called getClip().  Yay, we have Clip!
Now all we need to do is clip.open(AudioInputStream)... hmm.  Where do I get one of those?  The tutorial doesn't seem to say.
The official Javadocs have a neat feature where each interface lists all public classes that implement it.
What it does NOT have is a list of all methods whose return type "matches" the interface.
But that's okay, we have nice IDEs, so I can just "find usages" of AudioInputStream and filter down to those where it appears as a return type!
And there we go: I need AudioSystem.getAudioInputStream().
And then we're ready: we can call start() and it will play our clip!
Hmm... I wonder if the call returns when playback starts or only when it ends... maybe we need a scratch thread so it doesn't block us?
Oh and let's not forget to close() the clip when we're done!

This API seems to try pretty hard to give experts everything they need.
But it doesn't cater very well to the use case of "I don't know what a mixer is, and I wish I didn't have to care!"
The highly-nonofficial sun.audio.AudioPlayer does a pretty good job for this use-case; there should ideally be something at LEAST that easy in an official, non-deprecated API.

Just my two cents.
Mark

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231223/43a099f0/attachment-0001.htm>

From simon at cjnash.com  Sun Dec 24 17:05:35 2023
From: simon at cjnash.com (Simon Nash)
Date: Sun, 24 Dec 2023 17:05:35 +0000
Subject: Integrated: 8321151: JDK-8294427 breaks Windows L&F on all older
 Windows versions
In-Reply-To: <GEQTUv2GcUZd10SOaZuNIpi-EoXcYQwcn3XtyodK9eI=.05d4d44d-be0f-4eb6-b06d-812e2eaed917@github.com>
References: <BHU7JELtMmo3_x5CudKGdZ8xArBnHGZT3moO1kO9Qvg=.e37e88ba-8089-453b-aad4-f667f1978279@github.com>
 <GEQTUv2GcUZd10SOaZuNIpi-EoXcYQwcn3XtyodK9eI=.05d4d44d-be0f-4eb6-b06d-812e2eaed917@github.com>
Message-ID: <9153d4da-dc43-321c-a8ce-ae3e4b874c18@cjnash.com>

On 22/12/2023 20:19, Rajat Mahajan wrote:
> On Thu, 21 Dec 2023 01:19:40 GMT, Rajat Mahajan <rmahajan at openjdk.org> wrote:
> This pull request has now been integrated.
>
> Changeset: f695ca58
> Author:    Rajat Mahajan <rmahajan at openjdk.org>
> Committer: Alexey Ivanov <aivanov at openjdk.org>
> URL:       https://git.openjdk.org/jdk/commit/f695ca588453265d6ad791c6a396197e8a53ba39
> Stats:     54 lines in 1 file changed: 43 ins; 2 del; 9 mod
>
> 8321151: JDK-8294427 breaks Windows L&F on all older Windows versions
>
> Reviewed-by: aivanov, achung
>
> -------------
>
> PR: https://git.openjdk.org/jdk/pull/17173
>
Thanks very much for your work on this, much appreciated.

Simon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231224/3ec85f21/attachment.htm>

From asemenov at openjdk.org  Mon Dec 25 12:30:48 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 25 Dec 2023 12:30:48 GMT
Subject: RFR: 8317771 [macos14] Expand/collapse a JTree using keyboard
 freezes the application in macOS 14 Sonoma
In-Reply-To: <sHSfScxHvWt0Sx5BSWF2On3DoeqhHRI34yn_5l59L9I=.33727004-60e5-4785-9f96-df0a2023d99c@github.com>
References: <7kSAuBxx0uNV2pNBUDuOi-K03gJQDqRZ54DweVziqbg=.796551db-f918-4cb9-99d8-2ac89596854d@github.com>
 <sHSfScxHvWt0Sx5BSWF2On3DoeqhHRI34yn_5l59L9I=.33727004-60e5-4785-9f96-df0a2023d99c@github.com>
Message-ID: <_TnQXl6SK395WUSKc9tolVFx6L9BODof-CNefNaELWM=.30f29b5e-fd2d-465c-b1da-57e18fc12043@github.com>

On Thu, 21 Dec 2023 21:13:14 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> NSAccessibility Outline is an accessibility representation of trees.
>> This representation requires that the visible children be represented as a flat array.
>> The child linearization algorithm available in ```CAccessibility.getChildrenAndRolesRecursive()``` is universal, i.e. suitable for any object with the role of a tree, but is not efficient, since it traverses the entire tree and selects suitable children.
>> For JTree, this algorithm can be optimized by using TreePath, but the old algorithm will have to be retained to maintain versatility.
>
> src/java.desktop/macosx/classes/sun/lwawt/macosx/CAccessibility.java line 799:
> 
>> 797:                         for (int i = 0; i < count; i++) {
>> 798:                             TreePath path = tree.getPathForRow(i);
>> 799:                             Accessible an = createAccessibleTreeNode(tree, path);
> 
> I see that you are creating the accessible tree node with reflection calling its constructor. Can you just elaborate if it is the only way to get hold of it and why getting a tree.getAccessible().getAccessibleChild(i) does not work or what kind of problem getting the tree node this way creates?

A little lower, the access algorithm is implemented in the way you showed.
But to speed things up, I want to avoid recursion through the native and for this it is easier to initialize those nodes that are present in the tree path through the constructor. Why do I propose to use reflection? Otherwise, you will either have to make the constructor of a double-nested class public, or create a chain of methods that allow you to instantiate this class through a new call in CAccessibility.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17165#discussion_r1436078711

From swinxythecat at gmail.com  Tue Dec 26 04:05:42 2023
From: swinxythecat at gmail.com (SWinxy)
Date: Mon, 25 Dec 2023 23:05:42 -0500
Subject: the easiest ways to play an audio clip are the discouraged ones
In-Reply-To: <MN2PR12MB361619370CCA9790E58D6A21F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
References: <MN2PR12MB3616B22F1211ECABC7D721EAF99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
 <MN2PR12MB3616013C893644BADEDAAC30F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
 <MN2PR12MB361619370CCA9790E58D6A21F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
Message-ID: <CAPRuVTVr6v18sHbpbaf2uRAH6Kqtp_8bGzvR18Ke=3UqbcK0qA@mail.gmail.com>

Hi Mark,

Even though the javadoc points to the Java Tutorials, the OpenJDK project
doesn't have any way of updating them. So much has changed since it was
written <https://docs.oracle.com/javase/tutorial/information/history.html>,
and any effort to make things better for developers to understand should be
redirected to improving the javadoc itself. Still, I would agree that the
documentation needs to be improved greatly, especially the package-info
files whose only message is to point to the increasingly-obsolete Java
Tutorials. Code-wise, better things are possible.

FWIW, I found AudioAction, a subclass of BasicLookAndFeel, which I hope
helps in any way possible. I've never touched this part of java.desktop, so
I can't be of much help.

SWinxy

On Sat, Dec 23, 2023 at 4:07?PM <mark.yagnatinsky at barclays.com> wrote:

> Also: the discouraged methods (applet-based and sun.audio.Player) are
> friendly enough to call Toolkit. getPCMConvertedAudioInputStream() for you.
>
> Of course, you could do that yourself, except? this is ALSO not exposed.
>
> So we need to re-implement that method.  Sigh.
>
> The ?official? way to do things should NOT be this hard!
>
>
>
> *From:* Yagnatinsky, Mark : Markets Pre Trade
> *Sent:* Saturday, December 23, 2023 12:02 AM
> *To:* 'client-libs-dev at openjdk.org' <client-libs-dev at openjdk.org>
> *Subject:* the easiest ways to play an audio clip are the discouraged ones
>
>
>
> Sorry for double-post; I think my fist attempt got blocked because I
> wasn?t subscribed.
>
> Also sorry if this is the wrong list; please redirect me if so.
>
> ALSO ALSO sorry if this is a bit of a disorganized rant, but I?m a bit
> frustrated.
>
>
>
> Suppose I have a sound file on my hard disk and want Java to play it.
>
> By copying random code snippets off the internet, we can discover
>
> sun.audio.AudioPlayer.player.start(java.io.InputStream file)
>
>
>
> Easy!  But wait, the sun.* packages are not officially exported and javac
> 8 complains, and with modules it likely complains even louder.
>
> Then we discover JavaFX has a nifty MediaPlayer which is almost as easy.
> But JavaFX is ?de-bundled? so that?s a bit annoying.
>
>
>
> No matter, we can use Applet.newAudioClip()!  We don?t want an applet,
> this API works fine without them.  Nice!
>
> But the entire applet namespace is deprecated, and even worse, it is
> deprecated for removal.
>
> (For the record, I think deprecating it makes sense, but deprecating it
> for removal was a bad idea and should be undone.  But I?m an outsider, so
> whatever.)
>
> Depending on things that are threatened to go away on possibly short
> notice seems risky, so let?s not.
>
>
>
> I see something called JMF (Java Media Framework) but that?s also not
> bundled, and hard to even find docs for.  Sigh.
>
>
>
> Let?s looks at something nice and official: the sound tutorial:
>
> https://docs.oracle.com/javase/tutorial/sound/playing.html
>
> Oh dear, that looks complicated.  I guess we need to somehow get Clip?
> How to do that?
>
> The tutorial has a big warning on top that it hasn?t been updated since
> Java 8 but I suspect it hasn?t been touched since Java 5 or longer.
>
> Well, in must have been touched a bit, since it uses Clip.class syntax
> which was added in Java 5.  But what it doesn?t have is any mention of
> these methods:
>
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4896221
>
> My best explanation is that they got added after the tutorial was written,
> and then the tutorial was never updated, which I think reduces the amount
> of good those methods do.
>
> But that?s okay because we found those methods, one of which is called
> getClip().  Yay, we have Clip!
>
> Now all we need to do is clip.open(AudioInputStream)? hmm.  Where do I get
> one of those?  The tutorial doesn?t seem to say.
>
> The official Javadocs have a neat feature where each interface lists all
> public classes that implement it.
>
> What it does NOT have is a list of all methods whose return type ?matches?
> the interface.
>
> But that?s okay, we have nice IDEs, so I can just ?find usages? of
> AudioInputStream and filter down to those where it appears as a return type!
>
> And there we go: I need AudioSystem.getAudioInputStream().
>
> And then we?re ready: we can call start() and it will play our clip!
>
> Hmm? I wonder if the call returns when playback starts or only when it
> ends? maybe we need a scratch thread so it doesn?t block us?
>
> Oh and let?s not forget to close() the clip when we?re done!
>
>
>
> This API seems to try pretty hard to give experts everything they need.
>
> But it doesn?t cater very well to the use case of ?I don?t know what a
> mixer is, and I wish I didn?t have to care!?
>
> The highly-nonofficial sun.audio.AudioPlayer does a pretty good job for
> this use-case; there should ideally be something at LEAST that easy in an
> official, non-deprecated API.
>
>
>
> Just my two cents.
>
> Mark
>
> This message is for information purposes only. It is not a recommendation,
> advice, offer or solicitation to buy or sell a product or service, nor an
> official confirmation of any transaction. It is directed at persons who are
> professionals and is intended for the recipient(s) only. It is not directed
> at retail customers. This message is subject to the terms at:
> https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see:
> https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html
> regarding marketing commentary from Barclays Sales and/or Trading desks,
> who are active market participants;
> https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html
> regarding our standard terms for Barclays Corporate and Investment Bank
> where we trade with you in principal-to-principal wholesale markets
> transactions; and in respect to Barclays Research, including disclosures
> relating to specific issuers, see: http://publicresearch.barclays.com.
> __________________________________________________________________________________
>
> If you are incorporated or operating in Australia, read these important
> disclosures:
> https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html
> .
>
> __________________________________________________________________________________
> For more details about how we use personal information, see our privacy
> notice: https://www.cib.barclays/disclosures/personal-information-use.html.
>
>
> __________________________________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231225/2f8be36e/attachment-0001.htm>

From rkannathpari at openjdk.org  Wed Dec 27 03:47:16 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 27 Dec 2023 03:47:16 GMT
Subject: RFR: 8320343 : Generate GIF images for
 AbstractButton/5049549/bug5049549.java [v6]
In-Reply-To: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
References: <EWlwUMzFbB9SRqkGlwwddjR1SJIQthF2Z6d0390BjrU=.410c96eb-b8cf-457b-9fc6-b790e3c9ed95@github.com>
Message-ID: <VgEiQcHVDcfIrE_QwivgQOqbFlnnoM_WsB1CKVNO8o4=.bed59b3e-cc0c-4035-979e-a9d245dc3e87@github.com>

> Hi Reviewers,
> 
> Updated the test and it will generate required images on the fly so storing and loading image from repo could be avoided. 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:

  Added final modifier

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17029/files
  - new: https://git.openjdk.org/jdk/pull/17029/files/14616c9d..02b2d3e8

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

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

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

From rkannathpari at openjdk.org  Wed Dec 27 05:17:15 2023
From: rkannathpari at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 27 Dec 2023 05:17:15 GMT
Subject: RFR: 8320673 : PageFormat/CustomPaper.java has no Pass/Fail buttons; 
 multiple instructions
Message-ID: <fjoe2kc7O0yj7VihsqkCcW4Kod_f74VEPTU0YkePLtw=.4d5db552-9798-4cb0-8fd5-547c82c117b5@github.com>

Hi Reviewers,

I have updated the test case. Now test has pass/fail option also test will execute two time for covering different cases which are part of the test.

Please review and let me know your suggestions.

Regards,
Renjith.

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

Commit messages:
 - Fixed white space error
 - Fixed white space error
 - Modified print function
 - JDK-8320673 : PageFormat/CustomPaper.java has no Pass/Fail buttons; multiple instructions

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

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

From mbaesken at openjdk.org  Thu Dec 28 09:54:57 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 28 Dec 2023 09:54:57 GMT
Subject: RFR: JDK-8320405: [Windows Server 2016]
 java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java
 shows issues in awt_Win32GraphicsDevice.cpp
Message-ID: <A-ey34iRMjhOnwJSIEv7uZpGAj_EcP4NAwVobyVxBbg=.ceb9e3df-cba8-4fb6-90f2-bc46c962cdf1@github.com>

When running with fastdebug binaries we run intermittent into the issue below in
jtreg test java/awt/image/MultiResolutionImage/MultiResolutionImageObserverTest.java .
Seems we miss checking of successful HBITMAP creation before calling GetDIBits.

  HDC hBMDC = this->GetDC();
  HBITMAP hBM = ::CreateCompatibleBitmap(hBMDC, 1, 1);
  VERIFY(::GetDIBits(hBMDC, hBM, 0, 1, NULL, gpBitmapInfo, DIB_RGB_COLORS));

in awt_Win32GraphicsDevice.cpp . Thats why the releast of hBMDC / hBM fails as well at the end of the function causing the seond and third warning.


Sat Nov 18 17:29:23 CET 2023

*********************
AWT Assertion Failure
*********************
::GetDIBits(hBMDC, hBM, 0, 1, 0, gpBitmapInfo, 0)
File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 184
GetLastError() is 57 : The parameter is incorrect.

Do you want to break into the debugger?
*********************
*********************
AWT Assertion Failure
*********************
::DeleteObject(hBM)
File 'e:\openjdk\openjdk-21u-windows_x86_64-dbg\jdk\src\java.desktop\windows\native\libawt\windows\awt_Win32GraphicsDevice.cpp', at line 297
GetLastError() is 57 : The parameter is incorrect.

So it seems, we should have some additional checks/tracing.

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

Commit messages:
 - JDK-8320405

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

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

From jbechberger at openjdk.org  Fri Dec 29 14:08:48 2023
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 29 Dec 2023 14:08:48 GMT
Subject: RFR: 8221261: deadlock of CInputMethod.characterIndexForPoint and
 webkit.InputMethodClientImpl.getLocationOffset
In-Reply-To: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
References: <7D1LCZ-9ssnx6-So5T8CO4w_S4UhweI0mTtPzuzsU5c=.647a909c-7887-4877-b7a7-22d23bb37017@github.com>
Message-ID: <fXuZ6N83jHsJQlbUDY0ULlbrC9ibWsSt3tRFPAGmvvs=.f48bf78e-0ee9-43d2-92fd-73f9c6b2bc80@github.com>

On Fri, 22 Dec 2023 11:27:00 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> A dead-lock is caused by the interaction of MacOS, the AWTEventQueue and JavaFX when the users pressed the Caps Lock key while the AWTEventQueue is processing another event (more on this in the issue). The bug depends on the specific timing of the event sending and can apparently be prevented by finishing all incoming OS events directly while the LWCToolkit.invokeAndWait method is executed.
> 
> This fix is tested and fixes the issue.
> 
> I attached a small
> [reproducer](https://github.com/openjdk/jdk/files/13751865/Archive.zip), just run it with `mvn install package javafx:run`.

That sounds like a good idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/17184#issuecomment-1872115798

From mark.yagnatinsky at barclays.com  Sun Dec 31 19:43:09 2023
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Sun, 31 Dec 2023 19:43:09 +0000
Subject: the easiest ways to play an audio clip are the discouraged ones
In-Reply-To: <MN2PR12MB36160E07A9B9FF5DB1B09FBDF998A@MN2PR12MB3616.namprd12.prod.outlook.com>
References: <MN2PR12MB3616B22F1211ECABC7D721EAF99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
 <MN2PR12MB3616013C893644BADEDAAC30F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
 <MN2PR12MB361619370CCA9790E58D6A21F99BA@MN2PR12MB3616.namprd12.prod.outlook.com>
 <CAPRuVTVr6v18sHbpbaf2uRAH6Kqtp_8bGzvR18Ke=3UqbcK0qA@mail.gmail.com>
 <MN2PR12MB36160E07A9B9FF5DB1B09FBDF998A@MN2PR12MB3616.namprd12.prod.outlook.com>
Message-ID: <MN2PR12MB36168351D36CF6AE14916061F963A@MN2PR12MB3616.namprd12.prod.outlook.com>

Resending; last one got blocked due to message size so trimming previous conversation

From: Yagnatinsky, Mark : Markets Pre Trade
Sent: Tuesday, December 26, 2023 12:18 AM
To: 'SWinxy' <swinxythecat at gmail.com>
Cc: client-libs-dev at openjdk.org
Subject: RE: the easiest ways to play an audio clip are the discouraged ones

Thanks for responding.  And thanks for the history page!!
The sad thing is that the issue is not just a documentation issue.
It really does takes around five dozen of lines of code to do accomplish the following task:
?play a sound file on my disk without leaking any resources?
(Or at least, I haven?t found a way to do it in much less than five dozen lines.)

AudioAction is also ?intern-ish?: it seems designed to be called from look & feel code.

As for the tutorials: I realize they are barely maintained and I wish they still were.
But I see they still get occasional updates.  Maybe this one could be improved.
I suspect the sound tutorial has had no big updates since 1998, though the history page you linked claims 2006 for Java 6? (but where?s getClip() then?)

But lack of good docs is merely the second-biggest problem.
The biggest is that the API provides no easy way to accomplish what should be a trivial task.
Ideally the following lines of code should Just Work:
javax.sound.Player.playAsync(url); // fire and forget; leaks nothing
javax.sound.Player.playAndWait(url); // returns once playback is done, leaks nothing.
I shouldn?t have to know about ULAW vs ALAW vs PCM.
I shouldn?t even have to know about sampled vs midi.
(For nontrivial things, obviously those are very different; but not for something this simple.)
I shouldn?t have to implement line listeners and create a countdown latch.
It really shouldn?t be this hard!
The current difficulty level is high enough that people will ask themselves:
?do I really need add sound support?  Maybe I can live without it??
It should be easy enough that you can do it on a whim!

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/client-libs-dev/attachments/20231231/778937f3/attachment-0001.htm>