` is used to format pieces of code, I decided not to indent the first-level `` elements to avoid indentation of the code inside.
>
> I don't have a problem with keeping it simple. If some one writing a test doesn't see the HTML interpreted, they'll quickly be able to figure out why.
> One thing about these and the other enhancements I see is that there's an (increasing) need for a nice bit of documentation in PassFailJFrame itself about all its features. 
> Easiest to do this as you are adding them, so a doc comment block can be started with this one.
> Probably as a class comment.
> 
> Suggested text
> /**
>  * PassFailJFrame documentation
>  * 
>  * Instructions for the user can be either plain text or HTML as supported by Swing.
>  * Text beginning with  is presumed to be HTML.
> */

@prrace I've added description on how to use `PassFailJFrame` to #15665, it handles both HTML formatting for instructions (this PR) as well as creating test UI by passing a method reference, or rather an implementation of an interface.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15660#discussion_r1369268704

From aivanov at openjdk.org  Mon Oct 23 21:22:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 23 Oct 2023 21:22:36 GMT
Subject: RFR: 8294156: Allow PassFailJFrame.Builder to create test UI [v3]
In-Reply-To: 
References: 

 <80EWWL3FSNahyei94fPqu9XLOceu_wt-Xw7abes--_8=.a3b5ec1b-b0b2-4f76-847e-36a31af83976@github.com>

Message-ID: 

On Mon, 23 Oct 2023 20:59:49 GMT, Alexey Ivanov  wrote:

>>> > Shouldn't we mention here a window added by `testUI` via builder?
>>> 
>>> I don't think it's necessary: the builder uses `addTestWindow` under the hood. It's the builder that requires documentation.
>>> 
>>> In fact, the entire class requires a bit of TLC for documentation. I even wrote some after Lawrence @lawrence-andrew created the first version of `PassFailJFrame` but I never finished it. Even this part was implemented nearly a year ago.
>>> 
>>> I plan to create a wiki page on the [client-libs wiki](https://wiki.openjdk.org/display/ClientLibs) to describe creating manual tests with `PassFailJFrame`.
>> 
>> Just saw this, and it mirrors what I wrote in another PR that we need docs, but I believe they are best placed inside the source itself. Not everyone who can update this source can update the wiki.
>> That doesn't preclude you from putting more examples on the wiki and a reference to it from the source but I still think there should be docs in the source.
>> 
>> Include how to use this feature and something like to the builder example you have here might be good too.
>
> @prrace I've just pushed documentation on how to use `PassFailJFrame`. It provided two samples: the new one with the builder pattern and the classic one. The samples can be copied and pasted into a file, they're ready to run, except for imports and jtreg tags.

I also submitted a bug to provide more comprehensive documentation:  
[JDK-8318688](https://bugs.openjdk.org/browse/JDK-8318688): _Write documentation for PassFailJFrame_

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15665#discussion_r1369276650

From lkorinth at openjdk.org  Tue Oct 24 07:49:30 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 07:49:30 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 
Message-ID: 

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      *  Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      *  and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:

 - static import
 - copyright
 - whitespace
 - whitespace
 - sed
 - fix test/lib/jdk/test/lib/process/ProcessTools.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/f80dda8d..2f57a32d

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

  Stats: 1580 lines in 560 files changed: 44 ins; 34 del; 1502 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From lkorinth at openjdk.org  Tue Oct 24 09:10:43 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 09:10:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * 
 Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      *  and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Hi, if you want to see what I have modified manually, you can do my sed commands and compare to this pull request:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedTestJavaProcessBuilder/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createTestJvm/import static jdk.test.lib.process.ProcessTools.createTestJavaProcessBuilder/g"
git add -u; git commit -m sed

git diff-tree --no-commit-id --name-only -r 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9..HEAD | xargs sed -i -e "s%^( * Copyright (c) ....)[^[:alpha:]]*(Oracle.*)%\1, 2023, \2%"
git ls-files -m | xargs sed -i -e "s%(Copyright (c) 2023), 2023, (Oracle.*)%\1, \2%"
git add -u; git commit -m copyright

git diff HEAD 2f57a32df8d17da51a04177563327ca2a75e8061

It will give you an easier way to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1776817287

From stefank at openjdk.org  Tue Oct 24 09:51:39 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 24 Oct 2023 09:51:39 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * 
 Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      *  and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1694437335

From aivanov at openjdk.org  Tue Oct 24 11:04:52 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Oct 2023 11:04:52 GMT
Subject: RFR: 8316017: Refactor timeout handler in PassFailJFrame [v2]
In-Reply-To: 
References: 
Message-ID: <1ZPhiuQyo0KGDzWLP-TyRQvTPO9RQiNVe7u76iRC4Xs=.6dcab638-faae-42f4-be7b-27b095070d6a@github.com>

> Refactored timeout handling in PassFailJFrame:
> 
> 1. Managing the timer and formatting the time left is inside `TimeoutHandler` class.
> 2. The class handles timer events and updates the label accordingly.
> 
> This is implemented on top of #15665.

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

  Refactor failure reason

  Ensure the failure reason doesn't change after it's set.
  Removed 'failed' and 'timeout' fields:
  if failureReason is set, the test fails.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15668/files
  - new: https://git.openjdk.org/jdk/pull/15668/files/27f39736..39ebc7c8

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

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

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

From aivanov at openjdk.org  Tue Oct 24 11:22:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Oct 2023 11:22:36 GMT
Subject: RFR: 8316017: Refactor timeout handler in PassFailJFrame [v2]
In-Reply-To: 
References: 

Message-ID: <-4xuGFtlwOCJol4n15cIN8cXNPb2mrGdE0mkf-Af6rM=.70114749-aa9b-4beb-9dcb-d8bd7cacc34e@github.com>

On Tue, 19 Sep 2023 18:35:12 GMT, Phil Race  wrote:

>> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Refactor failure reason
>>   
>>   Ensure the failure reason doesn't change after it's set.
>>   Removed 'failed' and 'timeout' fields:
>>   if failureReason is set, the test fails.
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 329:
> 
>> 327:                 timer.stop();
>> 328:                 testFailedReason = FAILURE_REASON
>> 329:                                    + "Timeout User did not perform testing.";
> 
> If the test was explicitly failed by the user (ie failed==true), why does the reason say that there was a time out ?

@prrace Eventually, I refactored handling of `failureReason`.  I removed `failed` and `timeout` fields; the `failureReason` is set via a synchronised method to ensure there cannot be data race. If `failureReason` is not `null`, the test fails. After `failureReason` is set to a non-`null` value, it cannot be changed.

The timeout handler relies on this behaviour: it calls `setFailureReason` unconditionally; if `failureReason` is already set, the timeout reason is ignored.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15668#discussion_r1369999854

From lmesnik at openjdk.org  Tue Oct 24 17:04:41 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 24 Oct 2023 17:04:41 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1695447658

From prr at openjdk.org  Tue Oct 24 18:06:32 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Oct 2023 18:06:32 GMT
Subject: RFR: 8294156: Allow PassFailJFrame.Builder to create test UI [v3]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 23 Oct 2023 20:40:14 GMT, Alexey Ivanov  wrote:

>> This enhances the `Builder` pattern added in [JDK-8294535](https://bugs.openjdk.org/browse/JDK-8294535) with a new method `testUI` which allows passing a lambda expression or a method reference to create *the test UI window*.
>> 
>> The `PassFailJFrame` will automatically call the method on the EDT to create the UI, add it to the internal list of windows, install the window closing listener and finally position and show both the instructions and test UI.
>> 
>> Alternatively, you can pass an already created window.
>> 
>> The `main` method of a manual test could look as simple as a sequence of calls:
>> 
>> 
>>     public static void main(String[] args) throws Exception {
>>         PassFailJFrame.builder()
>>                       .instructions(INSTRUCTIONS)
>>                       .testUI(() -> createTestUI())
>>                       .build()
>>                       .awaitAndCheck();
>>     }
>> 
>> where `createTestUI` returns a test UI window.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add instructions on how to use PassFailJFrame

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15665#pullrequestreview-1695556451

From prr at openjdk.org  Tue Oct 24 18:12:32 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Oct 2023 18:12:32 GMT
Subject: RFR: 8316017: Refactor timeout handler in PassFailJFrame [v2]
In-Reply-To: <1ZPhiuQyo0KGDzWLP-TyRQvTPO9RQiNVe7u76iRC4Xs=.6dcab638-faae-42f4-be7b-27b095070d6a@github.com>
References: 
 <1ZPhiuQyo0KGDzWLP-TyRQvTPO9RQiNVe7u76iRC4Xs=.6dcab638-faae-42f4-be7b-27b095070d6a@github.com>
Message-ID: 

On Tue, 24 Oct 2023 11:04:52 GMT, Alexey Ivanov  wrote:

>> Refactored timeout handling in PassFailJFrame:
>> 
>> 1. Managing the timer and formatting the time left is inside `TimeoutHandler` class.
>> 2. The class handles timer events and updates the label accordingly.
>> 
>> This is implemented on top of #15665.
>
> Alexey Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor failure reason
>   
>   Ensure the failure reason doesn't change after it's set.
>   Removed 'failed' and 'timeout' fields:
>   if failureReason is set, the test fails.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15668#pullrequestreview-1695573011

From prr at openjdk.org  Tue Oct 24 18:13:30 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 24 Oct 2023 18:13:30 GMT
Subject: RFR: 8294158: HTML formatting for PassFailJFrame instructions
In-Reply-To: <_66glVfDeTgdOjLf6UFWUpvbLliLuQh-vhHmQnYaHBg=.a6500a45-7b96-4cff-b14d-cf0375becb72@github.com>
References: <_66glVfDeTgdOjLf6UFWUpvbLliLuQh-vhHmQnYaHBg=.a6500a45-7b96-4cff-b14d-cf0375becb72@github.com>
Message-ID: 

On Mon, 11 Sep 2023 13:11:10 GMT, Alexey Ivanov  wrote:

> This enhancement provides HTML formatting for instructions in the manual test framework, `PassFailJFrame`.
> 
> Some tests could benefit from rich-formatted instructions, especially when the instructions are long.
> 
> See a sample usage in #15661.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15660#pullrequestreview-1695578095

From aivanov at openjdk.org  Tue Oct 24 18:14:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Oct 2023 18:14:38 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 23 Oct 2023 20:48:31 GMT, ScientificWare  wrote:

> > What purpose does this distinction serve?
> 
> Definitely an application developer and because it's the context of this HTML implementation, may I preserve this distinction ?

Okay, let it be. However, I still think it's not the right thing.

There was nothing else but the `src` attribute, now there is.

> > This actually raises another question: what if altAtt isn't provided? Should it fallback to srcURL?
> 
> Yes, it's a logical error on my part.

Are you going to address it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1370634475

From honkar at openjdk.org  Tue Oct 24 18:35:31 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 24 Oct 2023 18:35:31 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 
Message-ID: 

> Harfbuzz upgraded from 7.2.0 to 8.2.2
> 
> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
> - 173 files modified.

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

  removed not needed DISABLED_WARNINGS flag for clang

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16322/files
  - new: https://git.openjdk.org/jdk/pull/16322/files/bcba463a..b6c6470b

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

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

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

From honkar at openjdk.org  Tue Oct 24 18:42:35 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 24 Oct 2023 18:42:35 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 24 Oct 2023 18:35:31 GMT, Harshitha Onkar  wrote:

>> Harfbuzz upgraded from 7.2.0 to 8.2.2
>> 
>> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
>> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
>> - 173 files modified.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed not needed DISABLED_WARNINGS flag for clang

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

> 501:    # expansion-to-defined required for GCC 9 builds. Not required for GCC 10+.
> 502:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type expansion-to-defined dangling-reference
> 503:    HARFBUZZ_DISABLED_WARNINGS_clang := missing-field-initializers

Removed `range-loop-analysis` disabled warning flag for clang. macOS build works with this change.

CI build works without array-bounds,  parentheses for HARFBUZZ_DISABLED_WARNINGS_gcc but since these flags were added recently to make build work on specific gcc versions [ [PR#14996](https://github.com/openjdk/jdk/pull/14996/files) and [PR#13859](https://github.com/openjdk/jdk/pull/13859/files) ], retaining it as-is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1370667019

From aivanov at openjdk.org  Tue Oct 24 18:57:39 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Oct 2023 18:57:39 GMT
Subject: RFR: 8169475 : WheelModifier.java fails by timeout [v2]
In-Reply-To: 
References: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>

Message-ID: 

On Mon, 23 Oct 2023 17:45:38 GMT, Alexey Ivanov  wrote:

> The updated test failed once on Linux when I ran the test on Friday?

I've run this test on all the platforms a few times more, no failures detected. So I consider that failure a one-off glitch.

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

PR Comment: https://git.openjdk.org/jdk/pull/16281#issuecomment-1777839177

From duke at openjdk.org  Tue Oct 24 18:57:40 2023
From: duke at openjdk.org (ScientificWare)
Date: Tue, 24 Oct 2023 18:57:40 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v2]
In-Reply-To: 
References: 

Message-ID: <__Q80iQTMdCxiJn8j77l5LGv86zuOv8AUFe28ha0tkI=.54fb2c65-499f-4364-9513-555520cb819b@github.com>

On Mon, 23 Oct 2023 12:09:35 GMT, Alexey Ivanov  wrote:

>> src/java.desktop/share/classes/javax/swing/text/html/FormView.java line 282:
>> 
>>> 280:                 @SuppressWarnings("deprecation")
>>> 281:                 URL srcURL = new URL(base, srcAtt);
>>> 282:                 ImageIcon icon = new ImageIcon(srcURL);
>> 
>> You should probably pass `altAtt` as the `description` parameter, yet I'm unsure if it's ever used in this context.
>
>> You should probably pass `altAtt` as the `description` parameter, yet I'm unsure if it's ever used in this context.
> 
> As I say, I'm unsure if it's used? The description could be exposed to Accessibility API. By default, `ImageIcon` uses the URL as the description if it isn't provided:
> 
> https://github.com/openjdk/jdk/blob/99de9bb83ff70fe81c89751516a86a94c8f552be/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L231-L233
> 
> Now that you handle the `alt` attribute, you can pass the description if it's provided.

![image](https://github.com/openjdk/jdk/assets/19194678/a98c058e-323f-49c5-af63-2f5b837b9b99)

Did you have this in mind ?

            String srcAtt = (String) attr.getAttribute(HTML.Attribute.SRC);
            String altAtt = (String) attr.getAttribute(HTML.Attribute.ALT);
            if (altAtt == null) {
                altAtt = srcAtt;
            }
            JButton button;
            try {
                URL base = ((HTMLDocument)getElement().getDocument()).getBase();
                @SuppressWarnings("deprecation")
                URL srcURL = new URL(base, srcAtt);
                ImageIcon icon = new ImageIcon(srcURL, altAtt);
                button = new JButton(icon);
            } catch (MalformedURLException e) {
                button = new JButton(altAtt == null ? srcAtt : altAtt);
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1370684162

From duke at openjdk.org  Tue Oct 24 19:06:37 2023
From: duke at openjdk.org (ScientificWare)
Date: Tue, 24 Oct 2023 19:06:37 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 24 Oct 2023 18:12:14 GMT, Alexey Ivanov  wrote:

>>> What purpose does this distinction serve?
>> 
>> Definitely an application developer and because it's the context of this HTML implementation, may I preserve this distinction ?
>> 
>>> This actually raises another question: what if altAtt isn't provided? Should it fallback to srcURL?
>> 
>> Yes, it's a logical error on my part.
>
>> > What purpose does this distinction serve?
>> 
>> Definitely an application developer and because it's the context of this HTML implementation, may I preserve this distinction ?
> 
> Okay, let it be. However, I still think it's not the right thing.
> 
> There was nothing else but the `src` attribute, now there is.
> 
>> > This actually raises another question: what if altAtt isn't provided? Should it fallback to srcURL?
>> 
>> Yes, it's a logical error on my part.
> 
> Are you going to address it?

![image](https://github.com/openjdk/jdk/assets/19194678/0c4ba14d-84df-4c45-abb2-f3f9dca01bd2)

- Left before the Patch
- Right with your suggestion and if the distinction is preserved.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1370696319

From dnguyen at openjdk.org  Tue Oct 24 19:16:27 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Tue, 24 Oct 2023 19:16:27 GMT
Subject: RFR: 8318100: Remove redundant check for Metal support
In-Reply-To: <5o31QXbBtHwEsAAdoj8Zw5m-OVneowbTaWhUx4p_mms=.0b329fa4-f3e9-43f1-b7df-216b6d22a86f@github.com>
References: <5o31QXbBtHwEsAAdoj8Zw5m-OVneowbTaWhUx4p_mms=.0b329fa4-f3e9-43f1-b7df-216b6d22a86f@github.com>
Message-ID: 

On Mon, 23 Oct 2023 16:46:24 GMT, Jayathirth D V  wrote:

> We have updated minimum macOS version on which JDK can be used to macOS 11 and we have check to enable metal pipeline only when macOS version is >=10.14.
> 
> Since minimum macOS version is updated we don't need this check now.
> Removed redundant check and ran all clientlibs tests on CI for verification.
> Also ran a sample program with different combination of sun.java2d.metal and sun.java2d.opengl flags and i see that appropriate pipeline is getting selected.

Changes look reasonable to me. Test results look good too

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16316#pullrequestreview-1695706623

From aivanov at openjdk.org  Tue Oct 24 19:21:30 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Oct 2023 19:21:30 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v2]
In-Reply-To: 
References: 

Message-ID: <7wuE9aFqxLJBW8h_yr2BJm51j3tnQWNtbdGp2q4PH14=.f0eaa11c-8dd4-49d3-93d3-974426298528@github.com>

On Tue, 24 Oct 2023 19:04:05 GMT, ScientificWare  wrote:

>>> > What purpose does this distinction serve?
>>> 
>>> Definitely an application developer and because it's the context of this HTML implementation, may I preserve this distinction ?
>> 
>> Okay, let it be. However, I still think it's not the right thing.
>> 
>> There was nothing else but the `src` attribute, now there is.
>> 
>>> > This actually raises another question: what if altAtt isn't provided? Should it fallback to srcURL?
>>> 
>>> Yes, it's a logical error on my part.
>> 
>> Are you going to address it?
>
> ![image](https://github.com/openjdk/jdk/assets/19194678/0c4ba14d-84df-4c45-abb2-f3f9dca01bd2)
> 
> 
> 
>             
>                 
>                     
>                     

>                     
>                     

>                     
>                     

>                     
>                     

>                     
>                     

>                     
>                     

>                 
>             
> 
> 
> - Left before the Patch
> - Right with your suggestion and if the distinction is preserved.

Yes, that's what I meant.

A button with the plain source is better than a button without a title at all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1370710100

From aivanov at openjdk.org  Tue Oct 24 19:30:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 24 Oct 2023 19:30:38 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v2]
In-Reply-To: <__Q80iQTMdCxiJn8j77l5LGv86zuOv8AUFe28ha0tkI=.54fb2c65-499f-4364-9513-555520cb819b@github.com>
References: 

 <__Q80iQTMdCxiJn8j77l5LGv86zuOv8AUFe28ha0tkI=.54fb2c65-499f-4364-9513-555520cb819b@github.com>
Message-ID: <0MGaVlAv8Javf1QqspsC-hE4l1Huy9QMoqTdCxZ5AJ8=.1b91e01e-b44a-4db1-a7a5-67f36e609d01@github.com>

On Tue, 24 Oct 2023 18:54:17 GMT, ScientificWare  wrote:

>>> You should probably pass `altAtt` as the `description` parameter, yet I'm unsure if it's ever used in this context.
>> 
>> As I say, I'm unsure if it's used? The description could be exposed to Accessibility API. By default, `ImageIcon` uses the URL as the description if it isn't provided:
>> 
>> https://github.com/openjdk/jdk/blob/99de9bb83ff70fe81c89751516a86a94c8f552be/src/java.desktop/share/classes/javax/swing/ImageIcon.java#L231-L233
>> 
>> Now that you handle the `alt` attribute, you can pass the description if it's provided.
>
> ![image](https://github.com/openjdk/jdk/assets/19194678/a98c058e-323f-49c5-af63-2f5b837b9b99)
> 
> Did you have this in mind ?
> 
>             
>                 
>                     
>                     

>                     
>                     

>                     
>                     

>                     
>                     

>                     
>                     

>                     
>                     

>                 
>             
> 
> 
> 
> 
>             String srcAtt = (String) attr.getAttribute(HTML.Attribute.SRC);
>             String altAtt = (String) attr.getAttribute(HTML.Attribute.ALT);
>             if (altAtt == null) {
>                 altAtt = srcAtt;
>             }
>             JButton button;
>             try {
>                 URL base = ((HTMLDocument)getElement().getDocument()).getBase();
>                 @SuppressWarnings("deprecation")
>                 URL srcURL = new URL(base, srcAtt);
>                 ImageIcon icon = new ImageIcon(srcURL, altAtt);
>                 button = new JButton(icon);
>             } catch (MalformedURLException e) {
>                 button = new JButton(altAtt == null ? srcAtt : altAtt);
>             }

Yes, something similar:

            String srcAtt = (String) attr.getAttribute(HTML.Attribute.SRC);
            String altAtt = (String) attr.getAttribute(HTML.Attribute.ALT);
            JButton button;
            try {
                URL base = ((HTMLDocument)getElement().getDocument()).getBase();
                @SuppressWarnings("deprecation")
                URL srcURL = new URL(base, srcAtt);
                ImageIcon icon = altAtt != null
                                 ? new ImageIcon(srcURL, altAtt)
                                 : new ImageIcon(srcURL);
                button = icon.getImageLoadStatus() == MediaTracker.COMPLETE
                         ? new JButton(icon)
                         : new JButton(altAtt != null ? altAtt : srcAtt);
            } catch (MalformedURLException e) {
                button = new JButton(altAtt != null ? altAtt : srcAtt);
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1370719498

From duke at openjdk.org  Tue Oct 24 19:35:36 2023
From: duke at openjdk.org (ScientificWare)
Date: Tue, 24 Oct 2023 19:35:36 GMT
Subject: RFR: JDK-8314731 : Add support for the alt attribute in the image
 type input HTML tag [v2]
In-Reply-To: <7wuE9aFqxLJBW8h_yr2BJm51j3tnQWNtbdGp2q4PH14=.f0eaa11c-8dd4-49d3-93d3-974426298528@github.com>
References: 

 <7wuE9aFqxLJBW8h_yr2BJm51j3tnQWNtbdGp2q4PH14=.f0eaa11c-8dd4-49d3-93d3-974426298528@github.com>
Message-ID: <0jhnoG73CtNim4AP-kiwmBMtAS_LmNTXCDp4Ld28WD8=.61b828ac-f0ee-4640-806f-de869cb7746f@github.com>

On Tue, 24 Oct 2023 19:18:20 GMT, Alexey Ivanov  wrote:

>> ![image](https://github.com/openjdk/jdk/assets/19194678/0c4ba14d-84df-4c45-abb2-f3f9dca01bd2)
>> 
>> 
>> 
>>             
>>                 
>>                     
>>                     

>>                     
>>                     

>>                     
>>                     

>>                     
>>                     

>>                     
>>                     

>>                     
>>                     

>>                 
>>             
>> 
>> 
>> - Left before the Patch
>> - Right with your suggestion and if the distinction is preserved.
>
> Yes, that's what I meant.
> 
> A button with the plain source is better than a button without a title at all.

> Are you going to address it?

Yes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15319#discussion_r1370724775

From rriggs at openjdk.org  Tue Oct 24 19:42:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 19:42:43 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: 
References: 

Message-ID: <6qyfRp98A2DA7Q7YhscmdmokkIvVVn9HxB_XjRdM47g=.615d7a65-e109-41db-b955-31c0a934debd@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

test/lib/jdk/test/lib/process/ProcessTools.java line 506:

> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List command) {
> 506:         return createTestJavaProcessBuilder(command.toArray(String[]::new));

The javadoc shoul d describe all of the options being added to the ProcessBuilder.
They were inadequated described previously and still are.
The other options (seem to be from the code), test.noclasspath, java.class.path, and test.thread.factory.
The description of test.thread.factory and addTestThreadFactoryArgs method seems inadequately described.

test/lib/jdk/test/lib/process/ProcessTools.java line 527:

> 525:      * Create ProcessBuilder using the java launcher from the jdk to
> 526:      * be tested.
> 527:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for `reateTestJavaProcessBuilder(...)`

test/lib/jdk/test/lib/process/ProcessTools.java line 549:

> 547:      * Create ProcessBuilder using the java launcher from the jdk to
> 548:      * be tested.
> 549:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for reateTestJavaProcessBuilder(...)

test/lib/jdk/test/lib/process/ProcessTools.java line 599:

> 597:      */
> 598:     public static OutputAnalyzer executeTestJvm(String... cmds) throws Exception {
> 599:         ProcessBuilder pb = createTestJavaProcessBuilder(cmds);

This should also describe *all* of the options being set in the ProcessBuilder before executing the process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370728371
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729609
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729925
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370730637

From duke at openjdk.org  Wed Oct 25 03:23:01 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Wed, 25 Oct 2023 03:23:01 GMT
Subject: RFR: 8169475 : WheelModifier.java fails by timeout [v3]
In-Reply-To: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>
References: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>
Message-ID: 

> Hi Reviewers,
> 
> I have added additional CountDownLatch for making sure button is visible before proceeding,(observe this was one of the key reason for failure) so this helps to improve test case stability. Modified _await()_ function by adding 1sec timeout with exception, this will help to reduce total execution time in case of failure. 
> Please review and let me know your suggestions, if any.

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

  Suggestions integrated

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16281/files
  - new: https://git.openjdk.org/jdk/pull/16281/files/2ef843df..56a06f12

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

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

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

From jdv at openjdk.org  Wed Oct 25 04:01:27 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 25 Oct 2023 04:01:27 GMT
Subject: RFR: 8318100: Remove redundant check for Metal support
In-Reply-To: <5bTDtWyT7qZIa3eD9aEF-tVFa5lepXdNcLSpMyUI7zk=.26dd8fee-51c4-4705-8ad4-7bea599cc054@github.com>
References: <5o31QXbBtHwEsAAdoj8Zw5m-OVneowbTaWhUx4p_mms=.0b329fa4-f3e9-43f1-b7df-216b6d22a86f@github.com>
 <5bTDtWyT7qZIa3eD9aEF-tVFa5lepXdNcLSpMyUI7zk=.26dd8fee-51c4-4705-8ad4-7bea599cc054@github.com>
Message-ID: 

On Mon, 23 Oct 2023 17:26:16 GMT, Sergey Bylokhov  wrote:

> Just wonder how the the java will work on 10.xx after JDK-8317970 integration, it will fail to start?

Yes. Last update to macOS Catalina was in Mid 2022 as mentioned at https://bugs.openjdk.org/browse/JDK-8317970.

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

PR Comment: https://git.openjdk.org/jdk/pull/16316#issuecomment-1778467635

From jdv at openjdk.org  Wed Oct 25 04:04:41 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 25 Oct 2023 04:04:41 GMT
Subject: Integrated: 8318100: Remove redundant check for Metal support
In-Reply-To: <5o31QXbBtHwEsAAdoj8Zw5m-OVneowbTaWhUx4p_mms=.0b329fa4-f3e9-43f1-b7df-216b6d22a86f@github.com>
References: <5o31QXbBtHwEsAAdoj8Zw5m-OVneowbTaWhUx4p_mms=.0b329fa4-f3e9-43f1-b7df-216b6d22a86f@github.com>
Message-ID: 

On Mon, 23 Oct 2023 16:46:24 GMT, Jayathirth D V  wrote:

> We have updated minimum macOS version on which JDK can be used to macOS 11 and we have check to enable metal pipeline only when macOS version is >=10.14.
> 
> Since minimum macOS version is updated we don't need this check now.
> Removed redundant check and ran all clientlibs tests on CI for verification.
> Also ran a sample program with different combination of sun.java2d.metal and sun.java2d.opengl flags and i see that appropriate pipeline is getting selected.

This pull request has now been integrated.

Changeset: 5ce718eb
Author:    Jayathirth D V 
URL:       https://git.openjdk.org/jdk/commit/5ce718eb175dd0855983577d41b0af57422f4a0e
Stats:     40 lines in 3 files changed: 0 ins; 39 del; 1 mod

8318100: Remove redundant check for Metal support

Reviewed-by: prr, dnguyen

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

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

From jdv at openjdk.org  Wed Oct 25 04:33:35 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 25 Oct 2023 04:33:35 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 24 Oct 2023 18:38:27 GMT, Harshitha Onkar  wrote:

>> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed not needed DISABLED_WARNINGS flag for clang
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 503:
> 
>> 501:    # expansion-to-defined required for GCC 9 builds. Not required for GCC 10+.
>> 502:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type expansion-to-defined dangling-reference
>> 503:    HARFBUZZ_DISABLED_WARNINGS_clang := missing-field-initializers
> 
> Removed `range-loop-analysis` disabled warning flag for clang. macOS build works with this change.
> 
> CI build works without array-bounds,  parentheses for HARFBUZZ_DISABLED_WARNINGS_gcc but since these flags were added recently to make build work on specific gcc versions [ [PR#14996](https://github.com/openjdk/jdk/pull/14996/files) and [PR#13859](https://github.com/openjdk/jdk/pull/13859/files) ], retaining it as-is.

Any specific reason why we need to remove `range-loop-analysis` flag as part of this update? Were there any build issues?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1371138825

From psadhukhan at openjdk.org  Wed Oct 25 07:26:42 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Oct 2023 07:26:42 GMT
Subject: Integrated: 8318102: macos10.14 check in CSystemColors can be removed.
In-Reply-To: 
References: 
Message-ID: 

On Mon, 16 Oct 2023 07:43:06 GMT, Prasanta Sadhukhan  wrote:

> Since [ JDK-8317970](https://bugs.openjdk.org/browse/JDK-8317970) in integrated to make macOS 11 the minimum version to build jdk, the 10.14 check added in [JDK-8284166](https://bugs.openjdk.org/browse/JDK-8284166) is not needed and can be removed..

This pull request has now been integrated.

Changeset: d7205e69
Author:    Prasanta Sadhukhan 
URL:       https://git.openjdk.org/jdk/commit/d7205e690fe92464caee9122e11a88b4cc5c2c2d
Stats:     10 lines in 1 file changed: 0 ins; 8 del; 2 mod

8318102: macos10.14 check in CSystemColors can be removed.

Reviewed-by: prr, aivanov

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

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

From stefank at openjdk.org  Wed Oct 25 07:27:32 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Oct 2023 07:27:32 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: 
References: 

 <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>

Message-ID: 

On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs  wrote:

>> I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name.
>> 
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases.
>
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca
> 
> The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name.
> 
> There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added.
> @AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process.
> Every test writer should be aware that additional command line options may be mixed in.
> 
> There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures.
> 
> As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change.

@RogerRiggs You seem to know what you want w.r.t. the extra java doc comments. Could you help write those? Could we also do that as a separate RFE? I think that would make it easier to get this PR and the javadoc update through the door.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1778669353

From psadhukhan at openjdk.org  Wed Oct 25 08:20:44 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Wed, 25 Oct 2023 08:20:44 GMT
Subject: Withdrawn: JDK-6690019: JOptionPane obscured behind an always on top
 JFrame hangs UI
In-Reply-To: 
References: 
Message-ID: 

On Thu, 5 Oct 2023 16:43:17 GMT, Prasanta Sadhukhan  wrote:

> A JOptionPane message dialog owned by a JFrame which is not always on top can be obscured behind an `"always on top" JFrame`. Since the option pane is modal, one can't move the "always on top frame" to reveal it, so the application effectively hangs as we cannot dismiss the option pane dialog
> Fix is to make sure the option pane dialog is always on top....

This pull request has been closed without being integrated.

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

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

From lkorinth at openjdk.org  Wed Oct 25 08:44:29 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 25 Oct 2023 08:44:29 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 
Message-ID: 

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

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

  fix copyright year and indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/2f57a32d..4cc3865a

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

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

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

From aivanov at openjdk.org  Wed Oct 25 11:19:45 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 11:19:45 GMT
Subject: Integrated: 8294158: HTML formatting for PassFailJFrame instructions
In-Reply-To: <_66glVfDeTgdOjLf6UFWUpvbLliLuQh-vhHmQnYaHBg=.a6500a45-7b96-4cff-b14d-cf0375becb72@github.com>
References: <_66glVfDeTgdOjLf6UFWUpvbLliLuQh-vhHmQnYaHBg=.a6500a45-7b96-4cff-b14d-cf0375becb72@github.com>
Message-ID: 

On Mon, 11 Sep 2023 13:11:10 GMT, Alexey Ivanov  wrote:

> This enhancement provides HTML formatting for instructions in the manual test framework, `PassFailJFrame`.
> 
> Some tests could benefit from rich-formatted instructions, especially when the instructions are long.
> 
> See a sample usage in #15661.

This pull request has now been integrated.

Changeset: 14090ef6
Author:    Alexey Ivanov 
URL:       https://git.openjdk.org/jdk/commit/14090ef6039ff2f3064f397a75219b2bc715cc27
Stats:     40 lines in 1 file changed: 35 ins; 0 del; 5 mod

8294158: HTML formatting for PassFailJFrame instructions

Reviewed-by: azvegint, prr

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

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

From aivanov at openjdk.org  Wed Oct 25 11:29:49 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 11:29:49 GMT
Subject: RFR: 8294156: Allow PassFailJFrame.Builder to create test UI [v4]
In-Reply-To: 
References: 
Message-ID: 

> This enhances the `Builder` pattern added in [JDK-8294535](https://bugs.openjdk.org/browse/JDK-8294535) with a new method `testUI` which allows passing a lambda expression or a method reference to create *the test UI window*.
> 
> The `PassFailJFrame` will automatically call the method on the EDT to create the UI, add it to the internal list of windows, install the window closing listener and finally position and show both the instructions and test UI.
> 
> Alternatively, you can pass an already created window.
> 
> The `main` method of a manual test could look as simple as a sequence of calls:
> 
> 
>     public static void main(String[] args) throws Exception {
>         PassFailJFrame.builder()
>                       .instructions(INSTRUCTIONS)
>                       .testUI(() -> createTestUI())
>                       .build()
>                       .awaitAndCheck();
>     }
> 
> where `createTestUI` returns a test UI window.

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge master
 - Add instructions on how to use PassFailJFrame
 - 8294156: Allow creating several test windows

   The windows can be positioned in advance, or
   a call back PositionWindows interface can be used
   to define their positions after the instruction UI
   frame is positioned on the screen.
 - Remove trailing whitespace
 - Mark the Builder class final

   It's not supposed to be extended.
 - Amend message in window closing handler

   The WindowClosingHandler is used both for the instruction
   frame and for test UI windows.
   Also add blank lines to separate different parts of the class.
 - Use invokeOnEDT in getInstructionFrameBounds
 - Use functional style for disposing of windows

   Also clean up the doc for disposeWindows().
 - Use statically imported invokeAndWait and isEDT
 - Build functional test UI

   The Builder now provides a method to create test UI,
   PassFailJFrame automatically invokes the method reference
   on the EDT and then shows both the instruction frame and
   the test window.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/14090ef6...eff09d0d

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

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

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

From aivanov at openjdk.org  Wed Oct 25 11:30:55 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 11:30:55 GMT
Subject: RFR: 8316003: Update FileChooserSymLinkTest.java to HTML
 instructions [v4]
In-Reply-To: 
References: 
Message-ID: 

> To demonstrate the functionality of HTML formatting in `PassFailJFrame`, I updated the instructions for the `test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java` test. The commands to create the symbolic links are marked up with monospace font, which makes them stand out. The test instructions for single- and multi-selection are emphasised with bold text.
> 
> This change depends on #15660 and [JDK-8294158](https://bugs.openjdk.org/browse/JDK-8294158).

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge master
 - Amend indentation of nested 
 elements
 - Revert "Revert changes to FileChooserSymLinkTest.java"

   This reverts commit 7753b3f3e2d3a0df5fde672ad41833b6a9c6e247.
 - Wrap createUI call

   It reverts the accidental change where I unwrapped call to createUI
 - Revert changes to FileChooserSymLinkTest.java
 - Refactor configuration of a text component for instructions

   Each text component (JTextArea or JEditorPane) are configured
   in its own dedicated method. This avoids unnecessary type casts.
 - Improve instruction formatting
 - Enable HTML display if instructions start with 

   Instructions for FileChooserSymLinkTest are rendered in HTML.

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

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

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

From aivanov at openjdk.org  Wed Oct 25 11:34:44 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 11:34:44 GMT
Subject: Integrated: 8294156: Allow PassFailJFrame.Builder to create test UI
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 15:36:56 GMT, Alexey Ivanov  wrote:

> This enhances the `Builder` pattern added in [JDK-8294535](https://bugs.openjdk.org/browse/JDK-8294535) with a new method `testUI` which allows passing a lambda expression or a method reference to create *the test UI window*.
> 
> The `PassFailJFrame` will automatically call the method on the EDT to create the UI, add it to the internal list of windows, install the window closing listener and finally position and show both the instructions and test UI.
> 
> Alternatively, you can pass an already created window.
> 
> The `main` method of a manual test could look as simple as a sequence of calls:
> 
> 
>     public static void main(String[] args) throws Exception {
>         PassFailJFrame.builder()
>                       .instructions(INSTRUCTIONS)
>                       .testUI(() -> createTestUI())
>                       .build()
>                       .awaitAndCheck();
>     }
> 
> where `createTestUI` returns a test UI window.

This pull request has now been integrated.

Changeset: 42b9ac8a
Author:    Alexey Ivanov 
URL:       https://git.openjdk.org/jdk/commit/42b9ac8a07b540f4d7955a778923d24a876451cc
Stats:     442 lines in 1 file changed: 365 ins; 38 del; 39 mod

8294156: Allow PassFailJFrame.Builder to create test UI

Reviewed-by: azvegint, prr

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

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

From aivanov at openjdk.org  Wed Oct 25 11:36:35 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 11:36:35 GMT
Subject: Integrated: 8316003: Update FileChooserSymLinkTest.java to HTML
 instructions
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 13:28:40 GMT, Alexey Ivanov  wrote:

> To demonstrate the functionality of HTML formatting in `PassFailJFrame`, I updated the instructions for the `test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java` test. The commands to create the symbolic links are marked up with monospace font, which makes them stand out. The test instructions for single- and multi-selection are emphasised with bold text.
> 
> This change depends on #15660 and [JDK-8294158](https://bugs.openjdk.org/browse/JDK-8294158).

This pull request has now been integrated.

Changeset: c587211b
Author:    Alexey Ivanov 
URL:       https://git.openjdk.org/jdk/commit/c587211bf8c60a7a1f6cc63770c38ede6cb4e173
Stats:     43 lines in 1 file changed: 13 ins; 0 del; 30 mod

8316003: Update FileChooserSymLinkTest.java to HTML instructions

Reviewed-by: prr

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

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

From ihse at openjdk.org  Wed Oct 25 12:29:32 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 25 Oct 2023 12:29:32 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v3]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 20 Oct 2023 23:03:50 GMT, Phil Race  wrote:

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

src/java.base/share/classes/module-info.java line 151:

> 149:     exports jdk.internal.javac to
> 150:         java.compiler,
> 151:          java.desktop, // for ScopedValue

The indentation looks odd..?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15476#discussion_r1371674366

From aivanov at openjdk.org  Wed Oct 25 12:42:45 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 12:42:45 GMT
Subject: RFR: 8316017: Refactor timeout handler in PassFailJFrame [v3]
In-Reply-To: 
References: 
Message-ID: 

> Refactored timeout handling in PassFailJFrame:
> 
> 1. Managing the timer and formatting the time left is inside `TimeoutHandler` class.
> 2. The class handles timer events and updates the label accordingly.
> 
> This is implemented on top of #15665.

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge master
 - Refactor failure reason

   Ensure the failure reason doesn't change after it's set.
   Removed 'failed' and 'timeout' fields:
   if failureReason is set, the test fails.
 - 8316017: Refactor timeout handler in PassFailJFrame
 - Remove trailing whitespace
 - Mark the Builder class final

   It's not supposed to be extended.
 - Amend message in window closing handler

   The WindowClosingHandler is used both for the instruction
   frame and for test UI windows.
   Also add blank lines to separate different parts of the class.
 - Use invokeOnEDT in getInstructionFrameBounds
 - Use functional style for disposing of windows

   Also clean up the doc for disposeWindows().
 - Use statically imported invokeAndWait and isEDT
 - Build functional test UI

   The Builder now provides a method to create test UI,
   PassFailJFrame automatically invokes the method reference
   on the EDT and then shows both the instruction frame and
   the test window.
 - ... and 6 more: https://git.openjdk.org/jdk/compare/c587211b...f590891b

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

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

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

From aivanov at openjdk.org  Wed Oct 25 13:29:01 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 13:29:01 GMT
Subject: RFR: 8316025: Use testUI() method of PassFailJFrame.Builder in
 FileChooserSymLinkTest.java [v3]
In-Reply-To: 
References: 
Message-ID: <3cGupG6NYaG7snJMpE0TjngOy0Fv1Xw9Q9NiFnqdVwg=.9810c0ea-10f9-470c-9532-fadddc96a45a@github.com>

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

Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Amend indentation of nested 
 elements
 - Merge master
 - 8316025: Update the return type of createTestUI

   PassFailJFrame now supports creating a list of test windows
 - Merge branch '8294156-func-manual-TestUI' into 8316025-testUI-SymLinkTest
 - 8294156: Allow creating several test windows

   The windows can be positioned in advance, or
   a call back PositionWindows interface can be used
   to define their positions after the instruction UI
   frame is positioned on the screen.
 - Use testUI() and builder pattern to create test UI
 - Remove trailing whitespace
 - Mark the Builder class final

   It's not supposed to be extended.
 - Amend message in window closing handler

   The WindowClosingHandler is used both for the instruction
   frame and for test UI windows.
   Also add blank lines to separate different parts of the class.
 - Use invokeOnEDT in getInstructionFrameBounds
 - ... and 9 more: https://git.openjdk.org/jdk/compare/c587211b...0f4f67b3

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

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

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

From aivanov at openjdk.org  Wed Oct 25 13:30:45 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 13:30:45 GMT
Subject: Integrated: 8316017: Refactor timeout handler in PassFailJFrame
In-Reply-To: 
References: 
Message-ID: 

On Mon, 11 Sep 2023 18:18:28 GMT, Alexey Ivanov  wrote:

> Refactored timeout handling in PassFailJFrame:
> 
> 1. Managing the timer and formatting the time left is inside `TimeoutHandler` class.
> 2. The class handles timer events and updates the label accordingly.
> 
> This is implemented on top of #15665.

This pull request has now been integrated.

Changeset: 3abd7726
Author:    Alexey Ivanov 
URL:       https://git.openjdk.org/jdk/commit/3abd772672a4dfd984459283235f3b1d8fb28a49
Stats:     149 lines in 1 file changed: 92 ins; 33 del; 24 mod

8316017: Refactor timeout handler in PassFailJFrame

Reviewed-by: prr

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

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

From aivanov at openjdk.org  Wed Oct 25 14:22:41 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 14:22:41 GMT
Subject: RFR: 8316025: Use testUI() method of PassFailJFrame.Builder in
 FileChooserSymLinkTest.java [v3]
In-Reply-To: <3cGupG6NYaG7snJMpE0TjngOy0Fv1Xw9Q9NiFnqdVwg=.9810c0ea-10f9-470c-9532-fadddc96a45a@github.com>
References: 
 <3cGupG6NYaG7snJMpE0TjngOy0Fv1Xw9Q9NiFnqdVwg=.9810c0ea-10f9-470c-9532-fadddc96a45a@github.com>
Message-ID: 

On Wed, 25 Oct 2023 13:29:01 GMT, Alexey Ivanov  wrote:

>> This update to `FileChooserSymLinkTest.java` demonstrates the usage of the `testUI` method of the `PassFailJFrame.Builder` class to streamline creating the UI for manual tests.
>> 
>> The [`main` method](https://github.com/aivanov-jdk/jdk/blob/cb1835527d718226f1c6fdd85ff5986703ea356f/test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java#L110-L118) is a simple sequence of calls:
>> 
>> 
>>     public static void main(String[] args) throws Exception {
>>         PassFailJFrame.builder()
>>                       .instructions(INSTRUCTIONS)
>>                       .rows(35)
>>                       .columns(50)
>>                       .testUI(FileChooserSymLinkTest::createTestUI)
>>                       .build()
>>                       .awaitAndCheck();
>>     }
>> 
>> 
>> It's the most streamlined way of creating a manual test.
>> 
>> This change depends on #15665 and [JDK-8294156](https://bugs.openjdk.org/browse/JDK-8294156) as well as #15661, both of which depend on #15660.
>
> Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Amend indentation of nested 
 elements
>  - Merge master
>  - 8316025: Update the return type of createTestUI
>    
>    PassFailJFrame now supports creating a list of test windows
>  - Merge branch '8294156-func-manual-TestUI' into 8316025-testUI-SymLinkTest
>  - 8294156: Allow creating several test windows
>    
>    The windows can be positioned in advance, or
>    a call back PositionWindows interface can be used
>    to define their positions after the instruction UI
>    frame is positioned on the screen.
>  - Use testUI() and builder pattern to create test UI
>  - Remove trailing whitespace
>  - Mark the Builder class final
>    
>    It's not supposed to be extended.
>  - Amend message in window closing handler
>    
>    The WindowClosingHandler is used both for the instruction
>    frame and for test UI windows.
>    Also add blank lines to separate different parts of the class.
>  - Use invokeOnEDT in getInstructionFrameBounds
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/c587211b...0f4f67b3

@prrace, @azvegint Could you take a look?

The PR on which this one depends have been integrated now. The PR #15661 updated the instructions to HTML, this PR uses the functional style of creating test UI introduced in #15665.

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

PR Comment: https://git.openjdk.org/jdk/pull/15666#issuecomment-1779391142

From aivanov at openjdk.org  Wed Oct 25 15:20:34 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 25 Oct 2023 15:20:34 GMT
Subject: RFR: 8169475 : WheelModifier.java fails by timeout [v3]
In-Reply-To: 
References: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>

Message-ID: 

On Wed, 25 Oct 2023 03:23:01 GMT, Renjith Kannath Pariyangad  wrote:

>> Hi Reviewers,
>> 
>> I have added additional CountDownLatch for making sure button is visible before proceeding,(observe this was one of the key reason for failure) so this helps to improve test case stability. Modified _await()_ function by adding 1sec timeout with exception, this will help to reduce total execution time in case of failure. 
>> Please review and let me know your suggestions, if any.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Suggestions integrated

Changes requested by aivanov (Reviewer).

test/jdk/java/awt/event/MouseWheelEvent/WheelModifier/WheelModifier.java line 175:

> 173:             if (test.f != null) {
> 174:                 SwingUtilities.invokeAndWait(test.f::dispose);
> 175:             }

This is still not *thread-safe*, you've missed the suggested changes: the `null`-check must also be inside `invokeAndWait`:
Suggestion:

            SwingUtilities.invokeAndWait(() -> {
                if (test.f != null) {
                   test.f.dispose();
               }
            });

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

PR Review: https://git.openjdk.org/jdk/pull/16281#pullrequestreview-1697655892
PR Review Comment: https://git.openjdk.org/jdk/pull/16281#discussion_r1371943516

From honkar at openjdk.org  Wed Oct 25 17:18:36 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 25 Oct 2023 17:18:36 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 04:29:28 GMT, Jayathirth D V  wrote:

>> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 503:
>> 
>>> 501:    # expansion-to-defined required for GCC 9 builds. Not required for GCC 10+.
>>> 502:    HARFBUZZ_DISABLED_WARNINGS_CXX_gcc := class-memaccess noexcept-type expansion-to-defined dangling-reference
>>> 503:    HARFBUZZ_DISABLED_WARNINGS_clang := missing-field-initializers
>> 
>> Removed `range-loop-analysis` disabled warning flag for clang. macOS build works with this change.
>> 
>> CI build works without array-bounds,  parentheses for HARFBUZZ_DISABLED_WARNINGS_gcc but since these flags were added recently to make build work on specific gcc versions [ [PR#14996](https://github.com/openjdk/jdk/pull/14996/files) and [PR#13859](https://github.com/openjdk/jdk/pull/13859/files) ], retaining it as-is.
>
> Any specific reason why we need to remove `range-loop-analysis` flag as part of this update? Were there any build issues?

@jayathirthrao

I removed `range-loop-analysis` as part of cleaning up the disabled warning section. I see that the following flag was added as part of https://github.com/openjdk/jdk/pull/993 to disable warnings for clang on Xcode 12.
Details here: https://github.com/openjdk/jdk/pull/993#issuecomment-722382063.

I suppose we need to add it back then?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1372084539

From prr at openjdk.org  Wed Oct 25 17:52:35 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Oct 2023 17:52:35 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 17:14:27 GMT, Harshitha Onkar  wrote:

>> Any specific reason why we need to remove `range-loop-analysis` flag as part of this update? Were there any build issues?
>
> @jayathirthrao
> 
> Removed `range-loop-analysis` as part of cleaning up the disabled warning section. I see that the following flag was added as part of https://github.com/openjdk/jdk/pull/993 to disable warnings for clang on Xcode 12.
> Details here: https://github.com/openjdk/jdk/pull/993#issuecomment-722382063.
> 
> I suppose we need to add it back then?

It depends. Perhaps the code that triggered the warning is no longer the same ?
And we just moved to xcode 14 didn't we ? So xcode 12 is now 2 versions back.
What you could try is to take a repo WITHOUT the new version of harfbuzz (ie one without your PR),
remove the disabling of this warning and see if xcode 14 build it - if it does, then the issue is resolved by
the new xcode and we may still need it for the new change. If the problem is still there with xcode 14 and the old (ie current existing) code, then its resolved by the hb update and we definitely don't need it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1372120649

From honkar at openjdk.org  Wed Oct 25 18:03:34 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 25 Oct 2023 18:03:34 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 17:49:43 GMT, Phil Race  wrote:

>> @jayathirthrao
>> 
>> Removed `range-loop-analysis` as part of cleaning up the disabled warning section. I see that the following flag was added as part of https://github.com/openjdk/jdk/pull/993 to disable warnings for clang on Xcode 12.
>> Details here: https://github.com/openjdk/jdk/pull/993#issuecomment-722382063.
>> 
>> I suppose we need to add it back then?
>
> It depends. Perhaps the code that triggered the warning is no longer the same ?
> And we just moved to xcode 14 didn't we ? So xcode 12 is now 2 versions back.
> What you could try is to take a repo WITHOUT the new version of harfbuzz (ie one without your PR),
> remove the disabling of this warning and see if xcode 14 build it - if it does, then the issue is resolved by
> the new xcode and we may still need it for the new change. If the problem is still there with xcode 14 and the old (ie current existing) code, then its resolved by the hb update and we definitely don't need it.

@prrace Makes sense! Thank you for the info about how this can be double-checked. I'll check and update the disabled section accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1372132481

From honkar at openjdk.org  Wed Oct 25 19:43:15 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 25 Oct 2023 19:43:15 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v3]
In-Reply-To: 
References: 
Message-ID: <9o46xmDiwhg8jYNfuaHQRL__JfiqdBglMze1F3rWz5c=.e9def672-db3e-481b-8023-0a01aeab8233@github.com>

> Harfbuzz upgraded from 7.2.0 to 8.2.2
> 
> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
> - 173 files modified.

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

  reverted disabled warning: range-loop-analysis

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16322/files
  - new: https://git.openjdk.org/jdk/pull/16322/files/b6c6470b..4befbca0

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

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

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

From honkar at openjdk.org  Wed Oct 25 19:43:18 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Wed, 25 Oct 2023 19:43:18 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 18:00:58 GMT, Harshitha Onkar  wrote:

>> It depends. Perhaps the code that triggered the warning is no longer the same ?
>> And we just moved to xcode 14 didn't we ? So xcode 12 is now 2 versions back.
>> What you could try is to take a repo WITHOUT the new version of harfbuzz (ie one without your PR),
>> remove the disabling of this warning and see if xcode 14 build it - if it does, then the issue is resolved by
>> the new xcode and we may still need it for the new change. If the problem is still there with xcode 14 and the old (ie current existing) code, then its resolved by the hb update and we definitely don't need it.
>
> @prrace Makes sense! Thank you for the info about how this can be double-checked. I'll check and update the disabled section accordingly.

With existing harfbuzz v7.2.0 (without the update) + Xcode 14 build passes which implies that the issue was resolved on Xcode 14 and not harfbuzz. Hence adding back `range-loop-analysis` disabled warning.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1372245358

From rriggs at openjdk.org  Wed Oct 25 22:00:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Oct 2023 22:00:31 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Suggestions to complete the descriptions of the createXXXJavaProcessBuilder methods.

test/lib/jdk/test/lib/process/ProcessTools.java line 505:

> 503:      * @return The ProcessBuilder instance representing the java command.
> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List command) {

Include the same description of other properties that are included in creating the ProcessBuilder...
```     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 520:

> 518:      * @return The ProcessBuilder instance representing the java command.
> 519:      */
> 520:     public static ProcessBuilder createTestJavaProcessBuilder(String... command) {

Include the same description of other properties that are included in creating the ProcessBuilder...

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 538:

> 536:      * it in combination with @requires vm.flagless JTREG
> 537:      * anotation as to not waste energy and test resources.
> 538:      *

Consider adding this description of what this method does.
Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 560:

> 558:      * it in combination with @requires vm.flagless JTREG
> 559:      * anotation as to not waste energy and test resources.
> 560:      *

Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1698308785
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364800
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364171
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372361862
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372362333

From prr at openjdk.org  Wed Oct 25 23:27:37 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Oct 2023 23:27:37 GMT
Subject: RFR: 8305321: Remove unused exports in java.desktop [v5]
In-Reply-To: 
References: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>

Message-ID: 

On Fri, 13 Oct 2023 15:19:53 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that removes a number of unused exports from java.desktop native libraries.
>> 
>> In most cases I removed JNIEXPORT from methods and variables that are only used within a single shared library. Other than that:
>> - removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I could tell, rasterizer project is dead now, but if that's incorrect I can restore that export.
>> - removed `colorValueID` in X11Color; that field was not used.
>> - removed `J2dTraceInit` from header file. That method is only used internally by `J2dTraceImpl`.
>> 
>> The methods `Transform_GetInfo` and `Transform_transform` are declared in GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I should move them to where they are used.
>> 
>> The method `img_makePalette`, currently located in `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by `unix/native/common/awt/X11Color.c`; it could be moved to the same directory to avoid exporting the method from libawt. The files `img_colors.[ch]` do not have any references to other files in `cvutils`.
>> 
>> Manually verified that the exports are no longer present after these changes. Tier1-3 and client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Revert "Remove Color_initIDs"
>    
>    This reverts commit 8a8c9a63de14773905a64a8067ddd68c8a6ab137.
>  - Revert "Remove KeyboardFocusManager_initIDs"
>    
>    This reverts commit 66bd9a136b4c34d7d600ad49ce67fcd060160fb8.
>  - Revert "Remove Rectangle_initIDs"
>    
>    This reverts commit 0d21e361cd92215bbc8bb971b5c3f26898b96a0b.
>  - Revert "Remove Button_initIDs"
>    
>    This reverts commit 423afbf3b61cad504ae10a99ceb02c318f3a83ae.
>  - Revert "Remove FileDialog_initIDs"
>    
>    This reverts commit e66a9ffdda6e451c4298f59786adbd434dd1adb5.
>  - Revert "Remove TextField_initIDs"
>    
>    This reverts commit 0c3b78d27b899d4301f8326f90f1cc36703cbd3d.
>  - Revert "Update copyright"
>    
>    This reverts commit 5808c65e5fbabc08b43da982736b40db87000cb5.

I eyeballed this but I also ran all our automated tests on all platforms,
I don't know that I could be sure none of these were needed without doing that.

If we ever need to export any of these in the future it is easy enough to add it back.

src/java.desktop/share/native/common/font/sunfontids.h line 86:

> 84: 
> 85: /* Note: we share variable in the context of fontmanager lib
> 86:    but we need access method to use it from separate rasterizer lib */

That comment had nothing to do with the rasterizer OpenJDK project which wasn't even about font rasterisation. I think this refers to the closed source font rasteriser now removed. Anyway I don't think the comment is important enough to insist on keeping it.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13261#pullrequestreview-1698410666
PR Review Comment: https://git.openjdk.org/jdk/pull/13261#discussion_r1372412452

From prr at openjdk.org  Wed Oct 25 23:42:08 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 25 Oct 2023 23:42:08 GMT
Subject: RFR: 8318364: Add an FFM-based implementation of harfbuzz OpenType
 layout [v4]
In-Reply-To: 
References: 
Message-ID: 

> 8318364: Add an FFM-based implementation of harfbuzz OpenType layout

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

  indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15476/files
  - new: https://git.openjdk.org/jdk/pull/15476/files/2f759caf..c05f547d

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

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

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

From jdv at openjdk.org  Thu Oct 26 02:30:31 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Thu, 26 Oct 2023 02:30:31 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 19:37:37 GMT, Harshitha Onkar  wrote:

>> @prrace Makes sense! Thank you for the info about how this can be double-checked. I'll check and update the disabled section accordingly.
>
> With existing harfbuzz v7.2.0 (without the update) + Xcode 14 build passes which implies that the issue was resolved on Xcode 14 and not harfbuzz. Hence adding back `range-loop-analysis` disabled warning.

Since we know the reason for which this flag was added.
We should capture it in a comment, so that in future we will have faster way of analyzing it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1372502781

From serb at openjdk.org  Thu Oct 26 05:15:58 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 26 Oct 2023 05:15:58 GMT
Subject: RFR: 8318850: Duplicate code in the LCMSImageLayout
Message-ID: <5zipqunk528ENvO-I0VJ6RuSD3dNfXJZigxUUrWYux4=.95e236fd-a2cb-4aac-af6b-d9ab581d577a@github.com>

Small cleanup:
 * The code to handle the TYPE_XBYTE_XX and TYPE_BYTE_GRAY in the LCMSImageLayout  class is mostly identical, there is only one difference in offset calculation

                int firstBand = byteRaster.getSampleModel().getNumBands() - 1;
                l.offset = byteRaster.getDataOffset(firstBand);
or
                l.offset = byteRaster.getDataOffset(0);

But since the TYPE_BYTE_GRAY  has only one band, both codes calculate the same value. so we can simply remove the special branch for TYPE_BYTE_GRAY

 * the PREMUL_SH method is replaced by the constant PREMUL since we always pass the "1" as a parameter

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

Commit messages:
 - Update VerifyNumBands.java
 - 8318850: Duplicate code in the LCMSImageLayout

Changes: https://git.openjdk.org/jdk/pull/16371/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318850
  Stats: 75 lines in 2 files changed: 57 ins; 11 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16371/head:pull/16371

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

From duke at openjdk.org  Thu Oct 26 06:11:50 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Thu, 26 Oct 2023 06:11:50 GMT
Subject: RFR: 8169475 : WheelModifier.java fails by timeout [v4]
In-Reply-To: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>
References: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>
Message-ID: 

> Hi Reviewers,
> 
> I have added additional CountDownLatch for making sure button is visible before proceeding,(observe this was one of the key reason for failure) so this helps to improve test case stability. Modified _await()_ function by adding 1sec timeout with exception, this will help to reduce total execution time in case of failure. 
> Please review and let me know your suggestions, if any.

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

  Made thread safe

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16281/files
  - new: https://git.openjdk.org/jdk/pull/16281/files/56a06f12..8345c87b

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

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

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

From djelinski at openjdk.org  Thu Oct 26 06:15:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Oct 2023 06:15:42 GMT
Subject: RFR: 8305321: Remove unused exports in java.desktop [v5]
In-Reply-To: 
References: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>

Message-ID: <-9EtGVh5_hh_GdemaABB2-oB6eK3dKRmOMyTUxq--yk=.305d3f08-5082-4110-aebc-6d01f76346ad@github.com>

On Fri, 13 Oct 2023 15:19:53 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that removes a number of unused exports from java.desktop native libraries.
>> 
>> In most cases I removed JNIEXPORT from methods and variables that are only used within a single shared library. Other than that:
>> - removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I could tell, rasterizer project is dead now, but if that's incorrect I can restore that export.
>> - removed `colorValueID` in X11Color; that field was not used.
>> - removed `J2dTraceInit` from header file. That method is only used internally by `J2dTraceImpl`.
>> 
>> The methods `Transform_GetInfo` and `Transform_transform` are declared in GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I should move them to where they are used.
>> 
>> The method `img_makePalette`, currently located in `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by `unix/native/common/awt/X11Color.c`; it could be moved to the same directory to avoid exporting the method from libawt. The files `img_colors.[ch]` do not have any references to other files in `cvutils`.
>> 
>> Manually verified that the exports are no longer present after these changes. Tier1-3 and client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Revert "Remove Color_initIDs"
>    
>    This reverts commit 8a8c9a63de14773905a64a8067ddd68c8a6ab137.
>  - Revert "Remove KeyboardFocusManager_initIDs"
>    
>    This reverts commit 66bd9a136b4c34d7d600ad49ce67fcd060160fb8.
>  - Revert "Remove Rectangle_initIDs"
>    
>    This reverts commit 0d21e361cd92215bbc8bb971b5c3f26898b96a0b.
>  - Revert "Remove Button_initIDs"
>    
>    This reverts commit 423afbf3b61cad504ae10a99ceb02c318f3a83ae.
>  - Revert "Remove FileDialog_initIDs"
>    
>    This reverts commit e66a9ffdda6e451c4298f59786adbd434dd1adb5.
>  - Revert "Remove TextField_initIDs"
>    
>    This reverts commit 0c3b78d27b899d4301f8326f90f1cc36703cbd3d.
>  - Revert "Update copyright"
>    
>    This reverts commit 5808c65e5fbabc08b43da982736b40db87000cb5.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/13261#issuecomment-1780474713

From djelinski at openjdk.org  Thu Oct 26 06:15:45 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Oct 2023 06:15:45 GMT
Subject: RFR: 8305321: Remove unused exports in java.desktop [v5]
In-Reply-To: 
References: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>

Message-ID: 

On Wed, 25 Oct 2023 23:23:19 GMT, Phil Race  wrote:

>> Daniel Jeli?ski has updated the pull request incrementally with seven additional commits since the last revision:
>> 
>>  - Revert "Remove Color_initIDs"
>>    
>>    This reverts commit 8a8c9a63de14773905a64a8067ddd68c8a6ab137.
>>  - Revert "Remove KeyboardFocusManager_initIDs"
>>    
>>    This reverts commit 66bd9a136b4c34d7d600ad49ce67fcd060160fb8.
>>  - Revert "Remove Rectangle_initIDs"
>>    
>>    This reverts commit 0d21e361cd92215bbc8bb971b5c3f26898b96a0b.
>>  - Revert "Remove Button_initIDs"
>>    
>>    This reverts commit 423afbf3b61cad504ae10a99ceb02c318f3a83ae.
>>  - Revert "Remove FileDialog_initIDs"
>>    
>>    This reverts commit e66a9ffdda6e451c4298f59786adbd434dd1adb5.
>>  - Revert "Remove TextField_initIDs"
>>    
>>    This reverts commit 0c3b78d27b899d4301f8326f90f1cc36703cbd3d.
>>  - Revert "Update copyright"
>>    
>>    This reverts commit 5808c65e5fbabc08b43da982736b40db87000cb5.
>
> src/java.desktop/share/native/common/font/sunfontids.h line 86:
> 
>> 84: 
>> 85: /* Note: we share variable in the context of fontmanager lib
>> 86:    but we need access method to use it from separate rasterizer lib */
> 
> That comment had nothing to do with the rasterizer OpenJDK project which wasn't even about font rasterisation. I think this refers to the closed source font rasteriser now removed. Anyway I don't think the comment is important enough to insist on keeping it.

good to know, thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13261#discussion_r1372632269

From djelinski at openjdk.org  Thu Oct 26 06:15:46 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Oct 2023 06:15:46 GMT
Subject: Integrated: 8305321: Remove unused exports in java.desktop
In-Reply-To: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>
References: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>
Message-ID: <2dKOvRVBbTHB3TIq-Dp9Gau9mRtVQwhPRtmk4bkCGFU=.4112fe02-bfae-4841-b2a4-d076380e8373@github.com>

On Fri, 31 Mar 2023 07:34:50 GMT, Daniel Jeli?ski  wrote:

> Please review this patch that removes a number of unused exports from java.desktop native libraries.
> 
> In most cases I removed JNIEXPORT from methods and variables that are only used within a single shared library. Other than that:
> - removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I could tell, rasterizer project is dead now, but if that's incorrect I can restore that export.
> - removed `colorValueID` in X11Color; that field was not used.
> - removed `J2dTraceInit` from header file. That method is only used internally by `J2dTraceImpl`.
> 
> The methods `Transform_GetInfo` and `Transform_transform` are declared in GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I should move them to where they are used.
> 
> The method `img_makePalette`, currently located in `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by `unix/native/common/awt/X11Color.c`; it could be moved to the same directory to avoid exporting the method from libawt. The files `img_colors.[ch]` do not have any references to other files in `cvutils`.
> 
> Manually verified that the exports are no longer present after these changes. Tier1-3 and client libs tests still pass.

This pull request has now been integrated.

Changeset: 723db2dc
Author:    Daniel Jeli?ski 
URL:       https://git.openjdk.org/jdk/commit/723db2dc8651efb9e5da7754cbefb80f4171a367
Stats:     55 lines in 17 files changed: 3 ins; 21 del; 31 mod

8305321: Remove unused exports in java.desktop

Reviewed-by: aivanov, prr

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

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

From tr at openjdk.org  Thu Oct 26 10:19:45 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 26 Oct 2023 10:19:45 GMT
Subject: RFR: 5108458: JTable does not properly layout its content
Message-ID: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@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.

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

Commit messages:
 - Synth fix
 - Fix + Test

Changes: https://git.openjdk.org/jdk/pull/16374/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16374&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-5108458
  Stats: 293 lines in 3 files changed: 284 ins; 0 del; 9 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 djelinski at openjdk.org  Thu Oct 26 10:41:42 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 26 Oct 2023 10:41:42 GMT
Subject: RFR: 8318091: Remove empty initIDs functions
Message-ID: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>

The removed functions are empty on all platforms.

This patch also removes calls to `Toolkit.loadLibraries();` in classes that no longer have any native methods. The call was needed to ensure that the native awt library is loaded.

Client libs tests passed.

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

Commit messages:
 - Remove TextField_initIDs
 - Remove FileDialog_initIDs
 - Remove Button_initIDs
 - Remove Rectangle_initIDs
 - Remove KeyboardFocusManager_initIDs
 - Remove Color_initIDs

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

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

From tr at openjdk.org  Thu Oct 26 10:42:52 2023
From: tr at openjdk.org (Tejesh R)
Date: Thu, 26 Oct 2023 10:42:52 GMT
Subject: RFR: 5108458: JTable does not properly layout its content [v2]
In-Reply-To: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
References: <5cXVB1i8v2zt-F0c7Of8YgcOPX6lyEbmSR9ZxNklw8c=.664b54cc-5439-4680-8992-f20b58da0e91@github.com>
Message-ID: 

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

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

  Synth update

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

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

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

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

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

From aivanov at openjdk.org  Thu Oct 26 10:58:33 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Oct 2023 10:58:33 GMT
Subject: RFR: 8169475 : WheelModifier.java fails by timeout [v4]
In-Reply-To: 
References: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>

Message-ID: 

On Thu, 26 Oct 2023 06:11:50 GMT, Renjith Kannath Pariyangad  wrote:

>> Hi Reviewers,
>> 
>> I have added additional CountDownLatch for making sure button is visible before proceeding,(observe this was one of the key reason for failure) so this helps to improve test case stability. Modified _await()_ function by adding 1sec timeout with exception, this will help to reduce total execution time in case of failure. 
>> Please review and let me know your suggestions, if any.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made thread safe

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16281#pullrequestreview-1699301614

From aivanov at openjdk.org  Thu Oct 26 11:25:46 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Thu, 26 Oct 2023 11:25:46 GMT
Subject: RFR: 8305321: Remove unused exports in java.desktop [v5]
In-Reply-To: 
References: <5iIFg0d_PiJrYfcyLUbZmxZPfu9iuN5aOqxPpsWvt_I=.732a59c0-ec31-4a7b-a257-49a3f7c4f467@github.com>

Message-ID: 

On Fri, 13 Oct 2023 15:19:53 GMT, Daniel Jeli?ski  wrote:

>> Please review this patch that removes a number of unused exports from java.desktop native libraries.
>> 
>> In most cases I removed JNIEXPORT from methods and variables that are only used within a single shared library. Other than that:
>> - removed `getSunFontIDs` that was reportedly used by rasterizer; as far as I could tell, rasterizer project is dead now, but if that's incorrect I can restore that export.
>> - removed `colorValueID` in X11Color; that field was not used.
>> - removed `J2dTraceInit` from header file. That method is only used internally by `J2dTraceImpl`.
>> 
>> The methods `Transform_GetInfo` and `Transform_transform` are declared in GraphicsPrimitiveMgr, but are only used in TransformHelper. Let me know if I should move them to where they are used.
>> 
>> The method `img_makePalette`, currently located in `share/native/libawt/awt/image/cvutils/img_colors.c`, is only used by `unix/native/common/awt/X11Color.c`; it could be moved to the same directory to avoid exporting the method from libawt. The files `img_colors.[ch]` do not have any references to other files in `cvutils`.
>> 
>> Manually verified that the exports are no longer present after these changes. Tier1-3 and client libs tests still pass.
>
> Daniel Jeli?ski has updated the pull request incrementally with seven additional commits since the last revision:
> 
>  - Revert "Remove Color_initIDs"
>    
>    This reverts commit 8a8c9a63de14773905a64a8067ddd68c8a6ab137.
>  - Revert "Remove KeyboardFocusManager_initIDs"
>    
>    This reverts commit 66bd9a136b4c34d7d600ad49ce67fcd060160fb8.
>  - Revert "Remove Rectangle_initIDs"
>    
>    This reverts commit 0d21e361cd92215bbc8bb971b5c3f26898b96a0b.
>  - Revert "Remove Button_initIDs"
>    
>    This reverts commit 423afbf3b61cad504ae10a99ceb02c318f3a83ae.
>  - Revert "Remove FileDialog_initIDs"
>    
>    This reverts commit e66a9ffdda6e451c4298f59786adbd434dd1adb5.
>  - Revert "Remove TextField_initIDs"
>    
>    This reverts commit 0c3b78d27b899d4301f8326f90f1cc36703cbd3d.
>  - Revert "Update copyright"
>    
>    This reverts commit 5808c65e5fbabc08b43da982736b40db87000cb5.

I also ran the automated tests and I cross-referenced the imported symbols with exported ones on Windows and Linux.

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

PR Comment: https://git.openjdk.org/jdk/pull/13261#issuecomment-1780923747

From psadhukhan at openjdk.org  Thu Oct 26 12:47:35 2023
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Thu, 26 Oct 2023 12:47:35 GMT
Subject: RFR: 6928542: Chinese characters in RTF are not decoded [v7]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 21 Sep 2023 16:21:05 GMT, Ichiroh Takiguchi  wrote:

>> "character set of font" (font charset) table was created by "Rich Text Format Specification 1.9.1"
>> https://interoperability.blob.core.windows.net/files/Archive_References/[MSFT-RTF].pdf
>> It refers windgi.h
>> https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-textmetrica
>> 
>> Test files and testcase are in bugid [JDK-6928542](https://bugs.openjdk.org/browse/JDK-6928542)
>> 
>> Additional change:
>> Special character `\line` should `\n`
>> 
>> Additional information:
>> 
>> Add 2 hash tables
>> - fcharsetToCP: Predefined conversion table, `fcharset` with number control word, from control word to Java charset name, `fcharset0` refers `windows-1252` Java charset name
>> - fcharsetTable: Conversion table for each RTF file, `f` control word with number, from integer font numbers to Charset font charsets, In case of `{\f0\fnil\fcharset0 Segoe UI;}`, `0` refers Java Charset `windows-1252`
>> 
>> When RTF Character Set control word (like `\mac`) is used, unmappable character returns \u0000 and it's not written into RTF text..
>> When fcharset control word is used, unmappable character returns \uFFFD (it's the same as replacement character on decoder), \u0000 is used for DBCS lead byte detection.
>> If `f` or `par` control word is there and lead byte is remains on byte buffer for decoder, this byte data is as invalid character and write \uFFFD into RTF text.
>> 
>> If `f` control word is used without `fcharset`, `translationTable` char array is used.
>> If `f` control word is used with `fcharset`, predefined Java Charset name is used (if missing, ISO8859_1 is used for fallback).
>> 
>> **Note:** Following GitHub actions were failed
>> linux-cross-compile / build (riscv64), I opened following JBS.
>>> [JDK-8314624](https://bugs.openjdk.org/browse/JDK-8314624) GHA: RISC-V cross-build was failed
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6928542: Chinese characters in RTF are not decoded

For me the added regression test still fails with the fix in WIndows 10...anything I need to do more as a prerequisite?

Read data^M
=========^M
Gr\\u00fcezi -  Switzerland 0^M
\\u0082\\u00b1\\u0082\\u00f1\\u0082\\u00c9\\u0082\\u00bf\\u0082\\u00cd - Japanese 128^M
\\u00be\\u00c8\\u00b3\\u00e7\\u00c7\\u00cf\\u00bc\\u00bc\\u00bf\\u00e4 - Korean 129^M
\\u00c4\\u00e3\\u00ba\\u00c3 - China 134^M
\\u00bbO\\u00c6W - Traditional Chinese - Taiwan 136^M
\\u00e3\\u00e5\\u00e9\\u00e1 \\u00f3\\u00ef\\u00f5 - Greek 161^M
A\\u00f0a\\u00e7 - Turkish (Tree) 162^M
\\u00fe - Vietnam currency 163^M
\\u00f9\\u00c8\\u00d1\\u00ec\\u00e5\\u00c9\\u00ed - Hebrew 177^M
\\u00e3\\u00d1\\u00cd\\u00c8\\u00c7 - Arabic 178^M
A\\u00e8i\\u00fb - Lithuanian (Thank you) 186^M
\\u00c7\\u00e4\\u00f0\\u00e0\\u00e2\\u00f1\\u00f2\\u00e2\\u00f3\\u00e9\\u00f2\\u00e5 - Russian 204^M
\\u00ca\\u00c7\\u00d1\\u00ca\\u00b4\\u00d5 - Thailand 222^M
cze\\uc48f - Polish 238^M
^M
Expected data^M
=============^M
Gr\\u00fcezi -  Switzerland 0^M
\\u3053\\u3093\\u306b\\u3061\\u306f - Japanese 128^M
\\uc548\\ub155\\ud558\\uc138\\uc694 - Korean 129^M
\\u4f60\\u597d - China 134^M
\\u81fa\\u7063 - Traditional Chinese - Taiwan 136^M
\\u03b3\\u03b5\\u03b9\\u03b1 \\u03c3\\u03bf\\u03c5 - Greek 161^M
A\\u011fa\\u00e7 - Turkish (Tree) 162^M
\\u20ab - Vietnam currency 163^M
\\u05e9\\u05b8\\u05c1\\u05dc\\u05d5\\u05b9\\u05dd - Hebrew 177^M
\\u0645\\u0631\\u062d\\u0628\\u0627 - Arabic 178^M
A\\u010di\\u016b - Lithuanian (Thank you) 186^M
\\u0417\\u0434\\u0440\\u0430\\u0432\\u0441\\u0442\\u0432\\u0443\\u0439\\u0442\\u0435 - Russian 204^M
\\u0e2a\\u0e27\\u0e31\\u0e2a\\u0e14\\u0e35 - Thailand 222^M
cze\\u015b\\u0107 - Polish 238^M
^M
java.lang.RuntimeException: Test failed^M
        at RTFReadFontCharsetTest.main(RTFReadFontCharsetTest.java:114)^

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

PR Comment: https://git.openjdk.org/jdk/pull/13553#issuecomment-1781050285

From lkorinth at openjdk.org  Thu Oct 26 15:33:38 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 26 Oct 2023 15:33:38 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Would it be okay if we handle the new method documentation in a separate pull request? 

After applying your changes, I also noted that the existing description `The command line will be like: {test.jdk}/bin/java {test.vm.opts} {test.java.opts} cmds` is not only incorrect (or at least incomplete), but now also clashes with the added description. I then removed the sentence, but after I did that I also found out that similar wording exist in `executeTestJvm` and I fear that if I continue to pull strings, I will create more and more changes that you will have opinions on.

Is it all right if we push what we have now, and that I create a new pull requests with these improvements in documentation that are actually not related to the changes in this pull request?

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1781359450

From rriggs at openjdk.org  Thu Oct 26 16:29:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Oct 2023 16:29:40 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

ok, to correct the javadoc in a subsequent PR.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1700061972

From dmarkov at openjdk.org  Thu Oct 26 18:05:36 2023
From: dmarkov at openjdk.org (Dmitry Markov)
Date: Thu, 26 Oct 2023 18:05:36 GMT
Subject: RFR: 8169475 : WheelModifier.java fails by timeout [v4]
In-Reply-To: 
References: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>

Message-ID: 

On Thu, 26 Oct 2023 06:11:50 GMT, Renjith Kannath Pariyangad  wrote:

>> Hi Reviewers,
>> 
>> I have added additional CountDownLatch for making sure button is visible before proceeding,(observe this was one of the key reason for failure) so this helps to improve test case stability. Modified _await()_ function by adding 1sec timeout with exception, this will help to reduce total execution time in case of failure. 
>> Please review and let me know your suggestions, if any.
>
> Renjith Kannath Pariyangad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Made thread safe

Marked as reviewed by dmarkov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16281#pullrequestreview-1700218268

From honkar at openjdk.org  Thu Oct 26 18:39:19 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 26 Oct 2023 18:39:19 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v4]
In-Reply-To: 
References: 
Message-ID: 

> Harfbuzz upgraded from 7.2.0 to 8.2.2
> 
> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
> - 173 files modified.

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

  compiler warning flag info added as comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16322/files
  - new: https://git.openjdk.org/jdk/pull/16322/files/4befbca0..4e691c7e

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

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

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

From honkar at openjdk.org  Thu Oct 26 18:39:21 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Thu, 26 Oct 2023 18:39:21 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v2]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 26 Oct 2023 02:27:25 GMT, Jayathirth D V  wrote:

>> With existing harfbuzz v7.2.0 (without the update) + Xcode 14 build passes which implies that the issue was resolved on Xcode 14 and not harfbuzz. Hence adding back `range-loop-analysis` disabled warning.
>
> Since we know the reason for which this flag was added.
> We should capture it in a comment, so that in future we will have faster way of analyzing it.

Good point! Added the details as comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16322#discussion_r1373619854

From prr at openjdk.org  Thu Oct 26 19:08:30 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Oct 2023 19:08:30 GMT
Subject: RFR: 8318850: Duplicate code in the LCMSImageLayout
In-Reply-To: <5zipqunk528ENvO-I0VJ6RuSD3dNfXJZigxUUrWYux4=.95e236fd-a2cb-4aac-af6b-d9ab581d577a@github.com>
References: <5zipqunk528ENvO-I0VJ6RuSD3dNfXJZigxUUrWYux4=.95e236fd-a2cb-4aac-af6b-d9ab581d577a@github.com>
Message-ID: <_8VKEoZ7Ay_QCcLkG_h464T8GVvu9gIlBJmlb1c45hs=.a58ee2f5-b40b-406f-8bc5-c5d787c52493@github.com>

On Thu, 26 Oct 2023 01:14:57 GMT, Sergey Bylokhov  wrote:

> Small cleanup:
>  * The code to handle the TYPE_XBYTE_XX and TYPE_BYTE_GRAY in the LCMSImageLayout  class is mostly identical, there is only one difference in offset calculation
> 
>                 int firstBand = byteRaster.getSampleModel().getNumBands() - 1;
>                 l.offset = byteRaster.getDataOffset(firstBand);
> or
>                 l.offset = byteRaster.getDataOffset(0);
> 
> But since the TYPE_BYTE_GRAY  has only one band, both codes calculate the same value. so we can simply remove the special branch for TYPE_BYTE_GRAY
> 
>  * the PREMUL_SH method is replaced by the constant PREMUL since we always pass the "1" as a parameter

looks fine.

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16371#pullrequestreview-1700467141

From prr at openjdk.org  Thu Oct 26 19:28:33 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 26 Oct 2023 19:28:33 GMT
Subject: RFR: 8318091: Remove empty initIDs functions
In-Reply-To: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
References: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
Message-ID: 

On Thu, 26 Oct 2023 06:56:16 GMT, Daniel Jeli?ski  wrote:

> The removed functions are empty on all platforms.
> 
> This patch also removes calls to `Toolkit.loadLibraries();` in classes that no longer have any native methods. The call was needed to ensure that the native awt library is loaded.
> 
> Client libs tests passed.

Marked as reviewed by prr (Reviewer).

So this looks OK. The main thing I would worry about is that there isn't some code path which needs
the call to Toolkit.loadLibraries(), wasn't doing it itself, and gets by only because the libraries were loaded
by one of these calls being removed.

It is difficult to prove there is no such case. Tests may not be 100% coverage of all code paths.
Of course in such a case it is really a bug in that other code path, so if it shows up the fix would
likely be there rather than reverting some part of this change.

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

PR Review: https://git.openjdk.org/jdk/pull/16372#pullrequestreview-1700500301
PR Comment: https://git.openjdk.org/jdk/pull/16372#issuecomment-1781769779

From achung at openjdk.org  Thu Oct 26 23:08:59 2023
From: achung at openjdk.org (Alisen Chung)
Date: Thu, 26 Oct 2023 23:08:59 GMT
Subject: RFR: 8316028: Update FreeType to 2.13.2
Message-ID: 

Updating freetype
mach5 build is green

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

Commit messages:
 - fix whitespace and tabs
 - update freetype

Changes: https://git.openjdk.org/jdk/pull/16385/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16385&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316028
  Stats: 5484 lines in 100 files changed: 1565 ins; 2060 del; 1859 mod
  Patch: https://git.openjdk.org/jdk/pull/16385.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16385/head:pull/16385

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

From jdv at openjdk.org  Fri Oct 27 04:22:35 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 27 Oct 2023 04:22:35 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v4]
In-Reply-To: 
References: 

Message-ID: 

On Thu, 26 Oct 2023 18:39:19 GMT, Harshitha Onkar  wrote:

>> Harfbuzz upgraded from 7.2.0 to 8.2.2
>> 
>> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
>> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
>> - 173 files modified.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   compiler warning flag info added as comment

LGTM

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

Marked as reviewed by jdv (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16322#pullrequestreview-1700974480

From jdv at openjdk.org  Fri Oct 27 05:58:39 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Fri, 27 Oct 2023 05:58:39 GMT
Subject: RFR: 8318951: Additional negative value check in JPEG decoding
Message-ID: 

We skip jpeg data during decoding using imageio_skip_input_data() in both src/java.desktop/share/native/libjavajpeg/imageioJPEG.c and src/java.desktop/share/native/libjavajpeg/jpegdecoder.c

We update num_bytes with sb->remaining_skip in these functions and it can overflow. We need to add additional check for num_bytes here.

With updated code ran all awt and imageio tests in CI and it is green.

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

Commit messages:
 - 8318951: Additional negative value check in JPEG decoding

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

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

From mbaesken at openjdk.org  Fri Oct 27 07:55:03 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Oct 2023 07:55:03 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return
Message-ID: 

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

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

Commit messages:
 - JDK-8318955

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

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

From lkorinth at openjdk.org  Fri Oct 27 08:50:47 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 08:50:47 GMT
Subject: Integrated: 8315097: Rename createJavaProcessBuilder
In-Reply-To: 
References: 
Message-ID: 

On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth  wrote:

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

This pull request has now been integrated.

Changeset: d52a995f
Author:    Leo Korinth 
URL:       https://git.openjdk.org/jdk/commit/d52a995f35de26c2cc4074297a75141e4a363e1b
Stats:     1574 lines in 560 files changed: 44 ins; 10 del; 1520 mod

8315097: Rename createJavaProcessBuilder

Reviewed-by: lmesnik, dholmes, rriggs, stefank

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

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

From lkorinth at openjdk.org  Fri Oct 27 09:00:48 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:00:48 GMT
Subject: RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: 
References: 

Message-ID: 

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth  wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Thanks, see:
https://bugs.openjdk.org/browse/JDK-8318962

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1782552641

From duke at openjdk.org  Fri Oct 27 10:42:49 2023
From: duke at openjdk.org (null)
Date: Fri, 27 Oct 2023 10:42:49 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination
Message-ID: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@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)

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

Commit messages:
 - [macos14] InterJVMGetDropSuccessTest.java: Child VM: abnormal termination

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

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

From aivanov at openjdk.org  Fri Oct 27 11:00:38 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Oct 2023 11:00:38 GMT
Subject: RFR: 8318091: Remove empty initIDs functions
In-Reply-To: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
References: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
Message-ID: 

On Thu, 26 Oct 2023 06:56:16 GMT, Daniel Jeli?ski  wrote:

> The removed functions are empty on all platforms.
> 
> This patch also removes calls to `Toolkit.loadLibraries();` in classes that no longer have any native methods. The call was needed to ensure that the native awt library is loaded.
> 
> Client libs tests passed.

It looks good to me. The only concern I have, similar to Phil, is that peer implementations do not load the toolkit libraries. For this reason, I am for keeping the call to `Toolkit.loadLibraries()` in the static initializer of `java.awt.Button`, `java.awt.FileDialog`, `java.awt.KeyboardFocusManager` and `java.awt.TextField`.

src/java.desktop/share/classes/java/awt/Button.java line 128:

> 126:     static {
> 127:         /* ensure that the necessary native libraries are loaded */
> 128:         Toolkit.loadLibraries();

I think it is safer to preserve loading the toolkit libraries: `Button` is a peered component and I can't see any of the peers loads the libraries.

src/java.desktop/share/classes/java/awt/FileDialog.java line 146:

> 144:     static {
> 145:         /* ensure that the necessary native libraries are loaded */
> 146:         Toolkit.loadLibraries();

The same is here: I see no clear path to load the toolkit libraries from the peers, and peers do have native methods, including `initIDs`.

It looks as if peer implementations depend on the fact that the corresponding public API classes ensure the libraries are loaded.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16372#pullrequestreview-1701464849
PR Review Comment: https://git.openjdk.org/jdk/pull/16372#discussion_r1374373100
PR Review Comment: https://git.openjdk.org/jdk/pull/16372#discussion_r1374384221

From djelinski at openjdk.org  Fri Oct 27 11:04:36 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Oct 2023 11:04:36 GMT
Subject: RFR: 8318091: Remove empty initIDs functions
In-Reply-To: 
References: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>

Message-ID: 

On Fri, 27 Oct 2023 10:26:26 GMT, Alexey Ivanov  wrote:

>> The removed functions are empty on all platforms.
>> 
>> This patch also removes calls to `Toolkit.loadLibraries();` in classes that no longer have any native methods. The call was needed to ensure that the native awt library is loaded.
>> 
>> Client libs tests passed.
>
> src/java.desktop/share/classes/java/awt/Button.java line 128:
> 
>> 126:     static {
>> 127:         /* ensure that the necessary native libraries are loaded */
>> 128:         Toolkit.loadLibraries();
> 
> I think it is safer to preserve loading the toolkit libraries: `Button` is a peered component and I can't see any of the peers loads the libraries.

Button extends Component, which loads libraries

> src/java.desktop/share/classes/java/awt/FileDialog.java line 146:
> 
>> 144:     static {
>> 145:         /* ensure that the necessary native libraries are loaded */
>> 146:         Toolkit.loadLibraries();
> 
> The same is here: I see no clear path to load the toolkit libraries from the peers, and peers do have native methods, including `initIDs`.
> 
> It looks as if peer implementations depend on the fact that the corresponding public API classes ensure the libraries are loaded.

FileDialog extends Dialog, which loads libraries

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

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

From aivanov at openjdk.org  Fri Oct 27 11:12:36 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 27 Oct 2023 11:12:36 GMT
Subject: RFR: 8318091: Remove empty initIDs functions
In-Reply-To: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
References: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
Message-ID: 

On Thu, 26 Oct 2023 06:56:16 GMT, Daniel Jeli?ski  wrote:

> The removed functions are empty on all platforms.
> 
> This patch also removes calls to `Toolkit.loadLibraries();` in classes that no longer have any native methods. The call was needed to ensure that the native awt library is loaded.
> 
> Client libs tests passed.

> Button extends Component, which loads libraries
> FileDialog extends Dialog, which loads libraries

Then it's handled, obviously. `TextField` falls into the same category.

And `KeyboardFocusManager` will also load the libraries because it depends on the `Toolkit` class which, in its turn, loads the libraries.

We're good then, no further changes needed. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/16372#issuecomment-1782729139

From duke at openjdk.org  Fri Oct 27 11:51:43 2023
From: duke at openjdk.org (null)
Date: Fri, 27 Oct 2023 11:51:43 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length
Message-ID: 

JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.

The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.

import javax.sound.midi.*;

public class MidiTest {
    public static class RawMidiMessage extends MidiMessage {
        public RawMidiMessage(byte[] data) {
            super(data);
        }

        @Override
        public Object clone() {
            return new RawMidiMessage(this.getMessage());
        }
    }

    public static void main(String[] args) {
        var deviceInfos = MidiSystem.getMidiDeviceInfo();
        for (var info : deviceInfos) {
            try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
                if (device.getMaxReceivers() != 0) {
                    System.out.println("Open MIDI port: " + info.getName());
                    device.open();
                    Receiver receiver = device.getReceiver();
                    // Send two sysex messages at once
                    receiver.send(new RawMidiMessage(new byte[]{
                            (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
                            (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
                        }), -1);
                    // Send another sysex message
                    receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
                }
            } catch (MidiUnavailableException e) {
                e.printStackTrace();
            }
        }
    }
}

The expected messages received should be the following three messages

F0 7D 01 F7
F0 7D 02 F7
F0 7D 03 F7

But acually four messages was received with the second message repeated twice.

F0 7D 01 F7
F0 7D 02 F7
F0 7D 03 F7
F0 7D 02 F7

To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buffer hasn't been freed due to an error.

It seems that the patch may also resolve JDK-8250667. The extra bytes in the second sysex message is the same issue as JDK-8074211. I didn't figure out how the scrambled data generated in the third sysex message, but all the messages are correct after applying the patch.

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

Commit messages:
 - Resolve the message size issue when sending SysexMessage on Windows

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

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

From javasound-dev at bome.com  Fri Oct 27 16:03:37 2023
From: javasound-dev at bome.com (Florian Bomers)
Date: Fri, 27 Oct 2023 18:03:37 +0200
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length
In-Reply-To: 
References: 
Message-ID: <2972033c-b724-ec90-e9d6-6754ae2df178@bome.com>

Interesting!
I've reviewed this fix, it looks good to me.

For drivers that send Sys-Ex asynchronously, the dwBufferLength field 
/might /be read after the code sets it back to the temporary variable 
bufferLength. Trying to account for that would be much more work... 
But this fix will improve matters in any case.

Florian

On 27.10.2023 13:51, null wrote:
> JVM attempts to reuse the buffer for sending MIDI out data when the buffer size is enough. It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data. However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation. I've tested on Windows 7, 10 and 11. All of them have the same behavior.
>
> The bug cannot be easily reproduced because some MIDI drivers filter out any malformed MIDI data. The example code below create a special case to make sure all MIDI data are legally when the bug is triggered.
>
>
> import javax.sound.midi.*;
>
> public class MidiTest {
>      public static class RawMidiMessage extends MidiMessage {
>          public RawMidiMessage(byte[] data) {
>              super(data);
>          }
>
>          @Override
>          public Object clone() {
>              return new RawMidiMessage(this.getMessage());
>          }
>      }
>
>      public static void main(String[] args) {
>          var deviceInfos = MidiSystem.getMidiDeviceInfo();
>          for (var info : deviceInfos) {
>              try (MidiDevice device = MidiSystem.getMidiDevice(info)) {
>                  if (device.getMaxReceivers() != 0) {
>                      System.out.println("Open MIDI port: " + info.getName());
>                      device.open();
>                      Receiver receiver = device.getReceiver();
>                      // Send two sysex messages at once
>                      receiver.send(new RawMidiMessage(new byte[]{
>                              (byte) 0xF0, 0x7D, 0x01, (byte) 0xF7,
>                              (byte) 0xF0, 0x7D, 0x02, (byte) 0xF7
>                          }), -1);
>                      // Send another sysex message
>                      receiver.send(new RawMidiMessage(new byte[]{(byte) 0xF0, 0x7D, 0x03, (byte) 0xF7}), -1);
>                  }
>              } catch (MidiUnavailableException e) {
>                  e.printStackTrace();
>              }
>          }
>      }
> }
>
>
> The expected messages received should be the following three messages
>
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
>
>
> But acually four messages was received with the second message repeated twice.
>
> F0 7D 01 F7
> F0 7D 02 F7
> F0 7D 03 F7
> F0 7D 02 F7
>
>
> To resolve the issue, I add a new variable to backup the actual buffer size and set `dwBufferLength` of `MIDIHDR` structure to the size of MIDI data. After calling `midiOutLongMsg()`, I restore the original buffer size if the buffer hasn't been freed due to an error.
>
> It seems that the patch may also resolve JDK-8250667. The extra bytes in the second sysex message is the same issue as JDK-8074211. I didn't figure out how the scrambled data generated in the third sysex message, but all the messages are correct after applying the patch.
>
> -------------
>
> Commit messages:
>   - Resolve the message size issue when sending SysexMessage on Windows
>
> Changes:https://git.openjdk.org/jdk/pull/16399/files
>   Webrev:https://webrevs.openjdk.org/?repo=jdk&pr=16399&range=00
>    Issue:https://bugs.openjdk.org/browse/JDK-8074211
>    Stats: 7 lines in 1 file changed: 6 ins; 0 del; 1 mod
>    Patch:https://git.openjdk.org/jdk/pull/16399.diff
>    Fetch: git fetchhttps://git.openjdk.org/jdk.git  pull/16399/head:pull/16399
>
> PR:https://git.openjdk.org/jdk/pull/16399

-- 
Florian Bomers
Bome Software
/everything sounds./
https://www.bome.com
Bome Software GmbH & Co KG 	Gesellschafterin:
Petra-Kelly-Str. 15 	Bome Komplement?r GmbH
80797 M?nchen, Germany 	Gesch?ftsf?hrung: Florian B?mers
Amtsgericht M?nchen HRA95502 	Amtsgericht M?nchen HRB185574
LinkedIn  	YouTube 
 	Facebook 
 	Instagram 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From vdyakov at openjdk.org  Fri Oct 27 16:10:33 2023
From: vdyakov at openjdk.org (Victor Dyakov)
Date: Fri, 27 Oct 2023 16:10:33 GMT
Subject: RFR: 8318951: Additional negative value check in JPEG decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 05:54:04 GMT, Jayathirth D V  wrote:

> We skip jpeg data during decoding using imageio_skip_input_data() in both src/java.desktop/share/native/libjavajpeg/imageioJPEG.c and src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
> 
> We update num_bytes with sb->remaining_skip in these functions and it can overflow. We need to add additional check for num_bytes here.
> 
> With updated code ran all awt and imageio tests in CI and it is green.

@azvegint @prsadhuk please review

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

PR Comment: https://git.openjdk.org/jdk/pull/16390#issuecomment-1783166178

From djelinski at openjdk.org  Fri Oct 27 16:12:44 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 27 Oct 2023 16:12:44 GMT
Subject: Integrated: 8318091: Remove empty initIDs functions
In-Reply-To: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
References: <84AlWF9KBFAsGaFAXP17ms-spHQMxpUxi4l7NCJgWAI=.4fe9eb55-b148-403d-86b7-36af42d28b79@github.com>
Message-ID: 

On Thu, 26 Oct 2023 06:56:16 GMT, Daniel Jeli?ski  wrote:

> The removed functions are empty on all platforms.
> 
> This patch also removes calls to `Toolkit.loadLibraries();` in classes that no longer have any native methods. The call was needed to ensure that the native awt library is loaded.
> 
> Client libs tests passed.

This pull request has now been integrated.

Changeset: c593f8bf
Author:    Daniel Jeli?ski 
URL:       https://git.openjdk.org/jdk/commit/c593f8bf59dbe5d002c3b843796e54db6dd69bec
Stats:     364 lines in 17 files changed: 3 ins; 348 del; 13 mod

8318091: Remove empty initIDs functions

Reviewed-by: prr, aivanov

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

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

From serb at openjdk.org  Fri Oct 27 18:24:42 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Oct 2023 18:24:42 GMT
Subject: Integrated: 8318850: Duplicate code in the LCMSImageLayout
In-Reply-To: <5zipqunk528ENvO-I0VJ6RuSD3dNfXJZigxUUrWYux4=.95e236fd-a2cb-4aac-af6b-d9ab581d577a@github.com>
References: <5zipqunk528ENvO-I0VJ6RuSD3dNfXJZigxUUrWYux4=.95e236fd-a2cb-4aac-af6b-d9ab581d577a@github.com>
Message-ID: 

On Thu, 26 Oct 2023 01:14:57 GMT, Sergey Bylokhov  wrote:

> Small cleanup:
>  * The code to handle the TYPE_XBYTE_XX and TYPE_BYTE_GRAY in the LCMSImageLayout  class is mostly identical, there is only one difference in offset calculation
> 
>                 int firstBand = byteRaster.getSampleModel().getNumBands() - 1;
>                 l.offset = byteRaster.getDataOffset(firstBand);
> or
>                 l.offset = byteRaster.getDataOffset(0);
> 
> But since the TYPE_BYTE_GRAY  has only one band, both codes calculate the same value. so we can simply remove the special branch for TYPE_BYTE_GRAY
> 
>  * the PREMUL_SH method is replaced by the constant PREMUL since we always pass the "1" as a parameter

This pull request has now been integrated.

Changeset: d2260146
Author:    Sergey Bylokhov 
URL:       https://git.openjdk.org/jdk/commit/d2260146c9930002e430a874f2585d699dedc155
Stats:     75 lines in 2 files changed: 57 ins; 11 del; 7 mod

8318850: Duplicate code in the LCMSImageLayout

Reviewed-by: prr

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

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

From serb at openjdk.org  Fri Oct 27 18:38:32 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Oct 2023 18:38:32 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 11:10:45 GMT, Alec Su  wrote:

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

I think the java code in the description can be added as a testcase, even if it works fine before the patch, it is useful that the affected code will be triggered.
As an example you can use the tests in the next folder: https://github.com/openjdk/jdk/tree/master/test/jdk/javax/sound

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

PR Comment: https://git.openjdk.org/jdk/pull/16399#issuecomment-1783346826

From serb at openjdk.org  Fri Oct 27 18:50:31 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Oct 2023 18:50:31 GMT
Subject: RFR: 8318951: Additional negative value check in JPEG decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 05:54:04 GMT, Jayathirth D V  wrote:

> We skip jpeg data during decoding using imageio_skip_input_data() in both src/java.desktop/share/native/libjavajpeg/imageioJPEG.c and src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
> 
> We update num_bytes with sb->remaining_skip in these functions and it can overflow. We need to add additional check for num_bytes here.
> 
> With updated code ran all awt and imageio tests in CI and it is green.

I am not sure in what case this bug can be reproduced, but if it possible to get overflow there in the real app then probably we should skip that bytes in a few steps using small data?

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

PR Comment: https://git.openjdk.org/jdk/pull/16390#issuecomment-1783360995

From serb at openjdk.org  Fri Oct 27 18:53:32 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 27 Oct 2023 18:53:32 GMT
Subject: RFR: 8316028: Update FreeType to 2.13.2
In-Reply-To: 
References: 
Message-ID: <8M4_Oo55zF7JWCaTc8bI-RaYn8zpZnauD5s3KmYvjpw=.ebf8d882-75fd-4f08-bde2-c09d083e2356@github.com>

On Thu, 26 Oct 2023 21:45:46 GMT, Alisen Chung  wrote:

> Updating freetype
> mach5 build is green

Marked as reviewed by serb (Reviewer).

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

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

From honkar at openjdk.org  Fri Oct 27 18:59:12 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 27 Oct 2023 18:59:12 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v5]
In-Reply-To: 
References: 
Message-ID: 

> Harfbuzz upgraded from 7.2.0 to 8.2.2
> 
> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
> - 173 files modified.

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

  updated .md file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16322/files
  - new: https://git.openjdk.org/jdk/pull/16322/files/4e691c7e..3053354f

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

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

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

From prr at openjdk.org  Fri Oct 27 19:53:31 2023
From: prr at openjdk.org (Phil Race)
Date: Fri, 27 Oct 2023 19:53:31 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v5]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 27 Oct 2023 18:59:12 GMT, Harshitha Onkar  wrote:

>> Harfbuzz upgraded from 7.2.0 to 8.2.2
>> 
>> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
>> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
>> - 173 files modified.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated .md file

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16322#pullrequestreview-1702445654

From dnguyen at openjdk.org  Fri Oct 27 20:11:32 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 27 Oct 2023 20:11:32 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v5]
In-Reply-To: 
References: 

Message-ID: 

On Fri, 27 Oct 2023 18:59:12 GMT, Harshitha Onkar  wrote:

>> Harfbuzz upgraded from 7.2.0 to 8.2.2
>> 
>> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
>> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
>> - 173 files modified.
>
> Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated .md file

LGTM

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16322#pullrequestreview-1702474454

From azvegint at openjdk.org  Fri Oct 27 20:29:35 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Fri, 27 Oct 2023 20:29:35 GMT
Subject: RFR: 8316025: Use testUI() method of PassFailJFrame.Builder in
 FileChooserSymLinkTest.java [v3]
In-Reply-To: <3cGupG6NYaG7snJMpE0TjngOy0Fv1Xw9Q9NiFnqdVwg=.9810c0ea-10f9-470c-9532-fadddc96a45a@github.com>
References: 
 <3cGupG6NYaG7snJMpE0TjngOy0Fv1Xw9Q9NiFnqdVwg=.9810c0ea-10f9-470c-9532-fadddc96a45a@github.com>
Message-ID: 

On Wed, 25 Oct 2023 13:29:01 GMT, Alexey Ivanov  wrote:

>> This update to `FileChooserSymLinkTest.java` demonstrates the usage of the `testUI` method of the `PassFailJFrame.Builder` class to streamline creating the UI for manual tests.
>> 
>> The [`main` method](https://github.com/aivanov-jdk/jdk/blob/cb1835527d718226f1c6fdd85ff5986703ea356f/test/jdk/javax/swing/JFileChooser/FileChooserSymLinkTest.java#L110-L118) is a simple sequence of calls:
>> 
>> 
>>     public static void main(String[] args) throws Exception {
>>         PassFailJFrame.builder()
>>                       .instructions(INSTRUCTIONS)
>>                       .rows(35)
>>                       .columns(50)
>>                       .testUI(FileChooserSymLinkTest::createTestUI)
>>                       .build()
>>                       .awaitAndCheck();
>>     }
>> 
>> 
>> It's the most streamlined way of creating a manual test.
>> 
>> This change depends on #15665 and [JDK-8294156](https://bugs.openjdk.org/browse/JDK-8294156) as well as #15661, both of which depend on #15660.
>
> Alexey Ivanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:
> 
>  - Amend indentation of nested 
 elements
>  - Merge master
>  - 8316025: Update the return type of createTestUI
>    
>    PassFailJFrame now supports creating a list of test windows
>  - Merge branch '8294156-func-manual-TestUI' into 8316025-testUI-SymLinkTest
>  - 8294156: Allow creating several test windows
>    
>    The windows can be positioned in advance, or
>    a call back PositionWindows interface can be used
>    to define their positions after the instruction UI
>    frame is positioned on the screen.
>  - Use testUI() and builder pattern to create test UI
>  - Remove trailing whitespace
>  - Mark the Builder class final
>    
>    It's not supposed to be extended.
>  - Amend message in window closing handler
>    
>    The WindowClosingHandler is used both for the instruction
>    frame and for test UI windows.
>    Also add blank lines to separate different parts of the class.
>  - Use invokeOnEDT in getInstructionFrameBounds
>  - ... and 9 more: https://git.openjdk.org/jdk/compare/c587211b...0f4f67b3

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15666#pullrequestreview-1702493257

From duke at openjdk.org  Fri Oct 27 23:35:40 2023
From: duke at openjdk.org (lawrence.andrews)
Date: Fri, 27 Oct 2023 23:35:40 GMT
Subject: RFR: 8318580 :
 "javax/swing/MultiMonitor/MultimonVImage.java failing with Error. Can't find
 library: /open/test/jdk/java/awt/regtesthelpers" after JDK-8316053
Message-ID: <02Ibmd_1aWhnP0fQCk1cpZtrIp5OR--5HxF2alf3RI8=.785f9c15-704b-401a-b538-ef87943a0507@github.com>

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

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

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

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

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

From duke at openjdk.org  Sun Oct 29 14:19:03 2023
From: duke at openjdk.org (Alec Su)
Date: Sun, 29 Oct 2023 14:19:03 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v2]
In-Reply-To: 
References: 
Message-ID: 

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

Alec Su has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains two new commits since the last revision:

 - Add a testcase for the buffer issue on Windows
 - Resolve the message size issue when sending SysexMessage on Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16399/files
  - new: https://git.openjdk.org/jdk/pull/16399/files/16918dd5..a6b499f3

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

  Stats: 113 lines in 5 files changed: 84 ins; 2 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/16399.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16399/head:pull/16399

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

From duke at openjdk.org  Sun Oct 29 14:19:04 2023
From: duke at openjdk.org (Alec Su)
Date: Sun, 29 Oct 2023 14:19:04 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length
In-Reply-To: 
References: 

Message-ID: 

On Fri, 27 Oct 2023 18:35:33 GMT, Sergey Bylokhov  wrote:

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

Thanks for the suggestions from Florian Bomers and @mrserb.

I?ve added a new structure to record the actual buffer length. Therefore the actual buffer length doesn?t need to write back to dwBufferLength. Additionally, The example code is added as a testcase.

Please let me know if there are any further improvements needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/16399#issuecomment-1784126362

From duke at openjdk.org  Sun Oct 29 14:29:45 2023
From: duke at openjdk.org (Alec Su)
Date: Sun, 29 Oct 2023 14:29:45 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Code cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16399/files
  - new: https://git.openjdk.org/jdk/pull/16399/files/a6b499f3..819e2cff

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

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

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

From jdv at openjdk.org  Mon Oct 30 04:32:33 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Mon, 30 Oct 2023 04:32:33 GMT
Subject: RFR: 8318951: Additional negative value check in JPEG decoding
In-Reply-To: 
References: 

Message-ID: 

On Fri, 27 Oct 2023 18:48:17 GMT, Sergey Bylokhov  wrote:

> I am not sure in what case this bug can be reproduced, but if it possible to get overflow there in the real app then probably we should skip that bytes in a few steps using small data?

@mrserb yes in the current code there is no way we can hit overflow because streambuffer size is 4096 only and all skip_input_data() calls with some length are coming only from IJG and the length data is of 2 Bytes size. So `long num_bytes` cannot overflow in these scenarios. This is more of defense in depth fix for future scenarios.

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

PR Comment: https://git.openjdk.org/jdk/pull/16390#issuecomment-1784461503

From rschmelter at openjdk.org  Mon Oct 30 08:54:32 2023
From: rschmelter at openjdk.org (Ralf Schmelter)
Date: Mon, 30 Oct 2023 08:54:32 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 07:48:58 GMT, Matthias Baesken  wrote:

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

Maybe we should throw an OutOfMemoryError in addition, since otherwise the call looks like it has performed the operation.

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

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

From mbaesken at openjdk.org  Mon Oct 30 09:15:00 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Oct 2023 09:15:00 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: 
References: 
Message-ID: 

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

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

  Add JNU_ThrowOutOfMemoryError

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

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

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

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

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

From mbaesken at openjdk.org  Mon Oct 30 09:15:02 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Oct 2023 09:15:02 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 30 Oct 2023 08:52:04 GMT, Ralf Schmelter  wrote:

> Maybe we should throw an OutOfMemoryError in addition, since otherwise the call looks like it has performed the operation.

Makes probably sense, at other  places in the same file it is done this way. I added a JNU_ThrowOutOfMemoryError .

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

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

From rschmelter at openjdk.org  Mon Oct 30 11:52:34 2023
From: rschmelter at openjdk.org (Ralf Schmelter)
Date: Mon, 30 Oct 2023 11:52:34 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 30 Oct 2023 09:15:00 GMT, Matthias Baesken  wrote:

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

Looks good to me.

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

Marked as reviewed by rschmelter (Reviewer).

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

From mbaesken at openjdk.org  Mon Oct 30 12:47:32 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Oct 2023 12:47:32 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 30 Oct 2023 09:15:00 GMT, Matthias Baesken  wrote:

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

Hi Ralf, thanks for the review !

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

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

From jwaters at openjdk.org  Mon Oct 30 13:23:07 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 30 Oct 2023 13:23:07 GMT
Subject: RFR: 8307160: Fix AWT/2D/A11Y to support the permissive- flag on
 the Microsoft Visual C compiler [v9]
In-Reply-To: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
References: <7piLRto5nNbhYYYfENCr5ecm4M2xNtMkjkE8XhrLLQ0=.8fd1ac3a-46f8-47a8-ae37-a4abbf7757d9@github.com>
Message-ID: <69B1SjaCVySTnL6MTtdu4KFVeI8jKiNqLHTTlCw3Ykw=.c5efe789-23c9-45f5-99c2-e9414478f1bb@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:

  Split declaration and assignment in awt_Canvas.cpp

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

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

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

  Stats: 7 lines in 1 file changed: 0 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 azvegint at openjdk.org  Mon Oct 30 15:57:34 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Mon, 30 Oct 2023 15:57:34 GMT
Subject: RFR: 8318951: Additional negative value check in JPEG decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 05:54:04 GMT, Jayathirth D V  wrote:

> We skip jpeg data during decoding using imageio_skip_input_data() in both src/java.desktop/share/native/libjavajpeg/imageioJPEG.c and src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
> 
> We update num_bytes with sb->remaining_skip in these functions and it can overflow. We need to add additional check for num_bytes here.
> 
> With updated code ran all awt and imageio tests in CI and it is green.

Marked as reviewed by azvegint (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16390#pullrequestreview-1704512797

From honkar at openjdk.org  Mon Oct 30 18:05:04 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Mon, 30 Oct 2023 18:05:04 GMT
Subject: RFR: JDK-8313643: Update HarfBuzz to 8.2.2 [v6]
In-Reply-To: 
References: 
Message-ID: 

> Harfbuzz upgraded from 7.2.0 to 8.2.2
> 
> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
> - 173 files modified.

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

  .md file update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16322/files
  - new: https://git.openjdk.org/jdk/pull/16322/files/3053354f..13b62f89

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

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

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

From prr at openjdk.org  Mon Oct 30 20:41:31 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 30 Oct 2023 20:41:31 GMT
Subject: RFR: 8318951: Additional negative value check in JPEG decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 05:54:04 GMT, Jayathirth D V  wrote:

> We skip jpeg data during decoding using imageio_skip_input_data() in both src/java.desktop/share/native/libjavajpeg/imageioJPEG.c and src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
> 
> We update num_bytes with sb->remaining_skip in these functions and it can overflow. We need to add additional check for num_bytes here.
> 
> With updated code ran all awt and imageio tests in CI and it is green.

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16390#pullrequestreview-1705024302

From prr at openjdk.org  Mon Oct 30 20:48:31 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 30 Oct 2023 20:48:31 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 30 Oct 2023 09:15:00 GMT, Matthias Baesken  wrote:

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

src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c line 2303:

> 2301:     if (!pRect) {
> 2302:         (*env)->ReleaseIntArrayElements(env, bitmap, values, JNI_ABORT);
> 2303:         JNU_ThrowOutOfMemoryError(env, "malloc failed");

I think the throw is unnecessary. You will get some incorrect rendering, but that's all.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16392#discussion_r1376781142

From prr at openjdk.org  Mon Oct 30 21:32:31 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 30 Oct 2023 21:32:31 GMT
Subject: RFR: 8074211: javax.sound.midi: Error with send System Exclusive
 messages of different length [v3]
In-Reply-To: 
References: 

Message-ID: 

On Sun, 29 Oct 2023 14:29:45 GMT, Alec Su  wrote:

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

> It use `dwBytesRecorded` in `MIDIHDR` structure to indicate the actual size of the data
> However, `midiOutLongMsg()` ignores `dwBytesRecorded`, although it did not mentioned in the documentation.

This seems to be documented by Microsoft only in the most obscure fashion.

If you look at the doc for midiOutPrepareHeader
https://learn.microsoft.com/en-us/previous-versions/dd798477(v=vs.85)
it says "Before calling the function, set the lpData, dwBufferLength, and dwFlags members of the [MIDIHDR](https://learn.microsoft.com/en-us/previous-versions/dd798449(v=vs.85)) structure"

So no mention of dwBytesRecorded.

WAVEHDR is a very similar struct to MIDIHDR and if you look at this WAVEHDR doc it says

https://learn.microsoft.com/en-us/previous-versions/dd743837(v=vs.85)

    dwBytesRecorded
    When the header is used in input, specifies how much data is in the buffer.

So I infer the same is true for MIDI

Therefore dwBytesRecorded is only used for input and dwBufferLength is what's important for output.

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

PR Comment: https://git.openjdk.org/jdk/pull/16399#issuecomment-1786077861

From jdv at openjdk.org  Tue Oct 31 04:23:41 2023
From: jdv at openjdk.org (Jayathirth D V)
Date: Tue, 31 Oct 2023 04:23:41 GMT
Subject: Integrated: 8318951: Additional negative value check in JPEG decoding
In-Reply-To: 
References: 
Message-ID: 

On Fri, 27 Oct 2023 05:54:04 GMT, Jayathirth D V  wrote:

> We skip jpeg data during decoding using imageio_skip_input_data() in both src/java.desktop/share/native/libjavajpeg/imageioJPEG.c and src/java.desktop/share/native/libjavajpeg/jpegdecoder.c
> 
> We update num_bytes with sb->remaining_skip in these functions and it can overflow. We need to add additional check for num_bytes here.
> 
> With updated code ran all awt and imageio tests in CI and it is green.

This pull request has now been integrated.

Changeset: 75ce02fe
Author:    Jayathirth D V 
URL:       https://git.openjdk.org/jdk/commit/75ce02fe74e1232bfa8d72b4fdad82ed938ef957
Stats:     8 lines in 2 files changed: 8 ins; 0 del; 0 mod

8318951: Additional negative value check in JPEG decoding

Reviewed-by: azvegint, prr

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

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

From mbaesken at openjdk.org  Tue Oct 31 08:09:32 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 31 Oct 2023 08:09:32 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: 
References: 

Message-ID: 

On Mon, 30 Oct 2023 20:45:37 GMT, Phil Race  wrote:

>> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add JNU_ThrowOutOfMemoryError
>
> src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c line 2303:
> 
>> 2301:     if (!pRect) {
>> 2302:         (*env)->ReleaseIntArrayElements(env, bitmap, values, JNI_ABORT);
>> 2303:         JNU_ThrowOutOfMemoryError(env, "malloc failed");
> 
> I think the throw is unnecessary. You will get some incorrect rendering, but that's all.

So should I remove the  JNU_ThrowOutOfMemoryError ?  The calloc in the same file has a JNU_ThrowOutOfMemoryError (but maybe the situation is different there?)  .

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16392#discussion_r1377191445

From duke at openjdk.org  Tue Oct 31 09:26:10 2023
From: duke at openjdk.org (null)
Date: Tue, 31 Oct 2023 09:26:10 GMT
Subject: RFR: 8317287: [macos14] InterJVMGetDropSuccessTest.java: Child VM:
 abnormal termination [v2]
In-Reply-To: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
References: <9MoZ-LGXMsGUZtaExLSZKz0lQ6msanXuDBbUG7cI2d8=.25608504-5f64-4d89-9182-583d62c1bfde@github.com>
Message-ID: 

> 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)

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

  Update InterJVMGetDropSuccessTest.java

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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16396/files
  - new: https://git.openjdk.org/jdk/pull/16396/files/7598f7e2..a96950a5

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

  Stats: 26 lines in 1 file changed: 13 ins; 13 del; 0 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 prr at openjdk.org  Tue Oct 31 16:12:36 2023
From: prr at openjdk.org (Phil Race)
Date: Tue, 31 Oct 2023 16:12:36 GMT
Subject: RFR: JDK-8318955: Add ReleaseIntArrayElements in
 Java_sun_awt_X11_XlibWrapper_SetBitmapShape XlbWrapper.c to early return [v2]
In-Reply-To: 
References: 

Message-ID: 

On Tue, 31 Oct 2023 08:06:25 GMT, Matthias Baesken  wrote:

>> src/java.desktop/unix/native/libawt_xawt/xawt/XlibWrapper.c line 2303:
>> 
>>> 2301:     if (!pRect) {
>>> 2302:         (*env)->ReleaseIntArrayElements(env, bitmap, values, JNI_ABORT);
>>> 2303:         JNU_ThrowOutOfMemoryError(env, "malloc failed");
>> 
>> I think the throw is unnecessary. You will get some incorrect rendering, but that's all.
>
> So should I remove the  JNU_ThrowOutOfMemoryError ?  The calloc in the same file has a JNU_ThrowOutOfMemoryError (but maybe the situation is different there?)  .

Fair question. That other case is used only during initialisation and if they fail then some things are not set up properly.
So different enough. Yes, I think you can remove the one you are adding. If it ever happens it could be recoverable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16392#discussion_r1377841716

From duke at openjdk.org  Tue Oct 31 18:23:41 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 31 Oct 2023 18:23:41 GMT
Subject: Integrated: 8169475 : WheelModifier.java fails by timeout
In-Reply-To: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>
References: <6KNn6fI_9xTfU4881lMLCayoiHPWZAFdZMThs5vti3Q=.fa4bf75b-25c1-436e-b5d0-3984147b025b@github.com>
Message-ID: 

On Fri, 20 Oct 2023 06:59:17 GMT, Renjith Kannath Pariyangad  wrote:

> Hi Reviewers,
> 
> I have added additional CountDownLatch for making sure button is visible before proceeding,(observe this was one of the key reason for failure) so this helps to improve test case stability. Modified _await()_ function by adding 1sec timeout with exception, this will help to reduce total execution time in case of failure. 
> Please review and let me know your suggestions, if any.

This pull request has now been integrated.

Changeset: 613d32c2
Author:    Renjith Kannath Pariyangad 
Committer: Alexey Ivanov 
URL:       https://git.openjdk.org/jdk/commit/613d32c2822a443fdcb131a7d67c528410e9f7e6
Stats:     60 lines in 1 file changed: 41 ins; 9 del; 10 mod

8169475: WheelModifier.java fails by timeout

Reviewed-by: dmarkov, aivanov

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

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

From duke at openjdk.org  Tue Oct 31 18:23:51 2023
From: duke at openjdk.org (Renjith Kannath Pariyangad)
Date: Tue, 31 Oct 2023 18:23:51 GMT
Subject: Integrated: 8301846: Invalid TargetDataLine after screen lock when
 using JFileChooser or COM library
In-Reply-To: 
References: 
Message-ID: 

On Mon, 17 Jul 2023 05:52:30 GMT, Renjith Kannath Pariyangad  wrote:

> Hi Reviewers,
> 
> Observations :
> 1. Without com initialize if we access Mixer for recording, library loaded invalid GUID and clipped description in windows(ID not found in registry). With com initialization library load proper GUID (same as registry).
> 2. For Play back device always loading proper device GUID irrespective of com Initialization.
> 
> Test:
> Since screen lock and unlock workflow required for reproducing this issue, did coupe of iteration of manual testing post fix and confirmed its resolving the problem.
> To reconfirm nothing is broken, executed all audio related test cases on test bench post fix and all are green.
> 
> Please review the changes and let me know your comments if any.
> 
> Regards,
> Renjith.

This pull request has now been integrated.

Changeset: 613a3cc6
Author:    Renjith Kannath Pariyangad 
Committer: Alexey Ivanov 
URL:       https://git.openjdk.org/jdk/commit/613a3cc6896ef3c3f836d44de9b2fb05beba6e72
Stats:     167 lines in 2 files changed: 166 ins; 0 del; 1 mod

8301846: Invalid TargetDataLine after screen lock when using JFileChooser or COM library

Reviewed-by: serb, aivanov

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

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

From honkar at openjdk.org  Tue Oct 31 19:04:45 2023
From: honkar at openjdk.org (Harshitha Onkar)
Date: Tue, 31 Oct 2023 19:04:45 GMT
Subject: Integrated: JDK-8313643: Update HarfBuzz to 8.2.2
In-Reply-To: 
References: 
Message-ID: 

On Mon, 23 Oct 2023 19:18:56 GMT, Harshitha Onkar  wrote:

> Harfbuzz upgraded from 7.2.0 to 8.2.2
> 
> - 3 new files added - hb-subset-instancer-solver.cc, hb-subset-instancer-solver.hh, hb-subset-plan-member-list.hh
> - 2 files deleted - hb-subset-cff1.hh, hb-subset-cff2.hh
> - 173 files modified.

This pull request has now been integrated.

Changeset: 2182c936
Author:    Harshitha Onkar 
URL:       https://git.openjdk.org/jdk/commit/2182c93689f35c809f4d79a8002c838f8c4f56f3
Stats:     12812 lines in 179 files changed: 7127 ins; 1316 del; 4369 mod

8313643: Update HarfBuzz to 8.2.2

Reviewed-by: jdv, prr, dnguyen

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

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